rfc:protectedlookup
Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:protectedlookup [2008/06/01 10:45] – created robinf | rfc:protectedlookup [2008/06/03 13:52] – robinf | ||
---|---|---|---|
Line 3: | Line 3: | ||
* Date: 2008-06-01 | * Date: 2008-06-01 | ||
* Author: Robin Fernandes < | * Author: Robin Fernandes < | ||
+ | * First Published at: http:// | ||
* Status: in the works | * Status: in the works | ||
+ | |||
+ | |||
+ | |||
===== Introduction ===== | ===== Introduction ===== | ||
Line 9: | Line 13: | ||
This RFC proposes to eliminate an inconsistency in the way protected class members are resolved. | This RFC proposes to eliminate an inconsistency in the way protected class members are resolved. | ||
- | The fix to [[http:// | + | The fix to [[http:// |
However, this rule is not applied consistently for all types of method invocation. For example, a method that is visible when invoked directly may become invisible when invoked as a callback. Furthermore, | However, this rule is not applied consistently for all types of method invocation. For example, a method that is visible when invoked directly may become invisible when invoked as a callback. Furthermore, | ||
Line 15: | Line 19: | ||
This RFC investigates 3 alternatives to improve consistency: | This RFC investigates 3 alternatives to improve consistency: | ||
* Option 1: Remove the new lookup rule. | * Option 1: Remove the new lookup rule. | ||
- | * Option 2: Change all cases to match the new lookup rule. | + | * Option 2: Ensure |
* Option 3: Modify the new lookup rule to better match the intuitive/ | * Option 3: Modify the new lookup rule to better match the intuitive/ | ||
Line 154: | Line 158: | ||
?> | ?> | ||
</ | </ | ||
+ | |||
===== Some Details ===== | ===== Some Details ===== | ||
- | The new lookup rule is implemented | + | The new lookup rule is implemented by using '' |
<code c> | <code c> | ||
| | ||
Line 213: | Line 218: | ||
* The protected modifier loses its intuitive/ | * The protected modifier loses its intuitive/ | ||
| | ||
+ | |||
==== Option 3 ==== | ==== Option 3 ==== | ||
This approach is similar to option 2, but modifies the new rule slightly so as to preserve the intuitive meaning of the protected modifier. Lookups of protected members on sibling classes fall back to the declaration from the common ancestor class, if available. To illustrate: | This approach is similar to option 2, but modifies the new rule slightly so as to preserve the intuitive meaning of the protected modifier. Lookups of protected members on sibling classes fall back to the declaration from the common ancestor class, if available. To illustrate: | ||
Line 244: | Line 250: | ||
=== Cons === | === Cons === | ||
* Non-trivial code change | * Non-trivial code change | ||
- | * Possibly confusing at first, as code that reads C1::f() may in fact result in an invocation of P::f(). | + | * Possibly confusing at first, as code that reads C1::f() may in fact result in an invocation of P:: |
+ | <code php> | ||
+ | <?php | ||
+ | // Class P declares some private members. | ||
+ | class P { | ||
+ | private function f() { echo ' | ||
+ | public static function test() { | ||
+ | $c = new C; | ||
+ | $c-> | ||
+ | } | ||
+ | } | ||
+ | |||
+ | // Class C1 re-declares the " | ||
+ | class C extends P { | ||
+ | private function f() { echo ' | ||
+ | } | ||
+ | P::test(); | ||
+ | ?> | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Appendix ===== | ||
+ | ==== Other potential LSP violations ==== | ||
+ | If Option 1 is rejected on the grounds of a breach of LSP, then other arguable violations of LSP should be reviewed too. | ||
+ | Below is a list of examples to be considered. | ||
+ | === Private static methods === | ||
+ | <code php> | ||
+ | <?php | ||
+ | class P { | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | $class = get_class($liskov); | ||
+ | echo " | ||
+ | $liskov-> | ||
+ | echo " | ||
+ | $class:: | ||
+ | } | ||
+ | } | ||
+ | |||
+ | class C extends P { | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | P::test(new P); | ||
+ | P::test(new C); // Valid Liskov substitution - should this fail? | ||
+ | ?> | ||
+ | </ | ||
+ | === Private static properties === | ||
+ | <code php> | ||
+ | <?php | ||
+ | class P { | ||
+ | | ||
+ | | ||
+ | |||
+ | | ||
+ | $class = get_class($liskov); | ||
+ | echo " | ||
+ | echo $liskov-> | ||
+ | echo " | ||
+ | echo $class::$sa . " | ||
+ | } | ||
+ | } | ||
+ | |||
+ | class C extends P { | ||
+ | | ||
+ | | ||
+ | } | ||
+ | |||
+ | P::test(new P); | ||
+ | P::test(new C); // Valid Liskov substitution - should this fail? | ||
+ | ?> | ||
+ | </ |
rfc/protectedlookup.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1