Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Hi,
On Wed, Oct 31, 2012 at 12:16 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
I'm not sure why you are expecting this, and also this is probably an
LSP violation, since such override would change semantics of the value
that A clients expect. It may be possible to implement, technically, but
I'm not sure it's the right thing to do.
Why would it be not expected and/or a violation of LSP? Accessors
impose stricly more restrictions than properties. This code is fine.
You assume accessors are restrictions, but they don't have to be. Consider:
public $foo { get() { return $this-foo;} set($v) { $this-foo_copy =
$this-foo = $v; } }
You have a postcondition on set() that $this-foo_copy will be the same
as $this-foo. Override with public $foo removes that postcondition.
But proper inheritance should only strengthen the postconditions, not
drop them.
Well, LSP is typically not applied to program semantics, since this is
not a generally decidable problem. The only post-conditions that LSP
normally enforces is type based, i.e. the covariance of the return
type.
Instead, LSP simply states that, given B : A, all objects of A can be
substituted by objects of B while preserving the validity of the
method calls on these objects, and the validity of their return
values. This is guaranteed here:
a get accessor will return a value of type any when performing
$a-foo, so does a property. LSP checks.
a set accessor takes a argument, so does $a-foo = ... LSP checks.
My point is: all valid usages of accessors will also be valid when the
subclass overrides them using a normal property.
Just like it is fine in theory to have interface A { public $foo {
get(); set($v); } } class B implements A { public $foo; }
That's different. In this case, you say I will have some property
$foo, without promising anything about it. But specific code can
actually make some promises about $foo, and you can violate these
promises by overriding it with public $foo.
That's the same argument as before. Corresponding to LSP it only gives
very specific promises, that are simply type based and not the actual
strongest post-condition.
Interface does not impose
any conditions except that $foo exist and is gettable/settable. Specific
getters/setters can impose much more involved conditions, which public
$foo may not be able to satisfy.
Following your argument:
class A { public $v = 1; public foo() { $this-v = 2; } } class B
extends A {public foo() { $this-v = 4; }}
B should violate LSP, since the postcondition of B::foo() does not
imply postcondition of A::foo(). This is obviously not correct: this
code is fine.
Best,
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
Etienne Kneuss
http://www.colder.ch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Nikita, your examples convinced me that a strict accessor methods as
specialized __get/__set semantics approach is undesirable.
To recapitulate your two examples:
Example 1:
class A {
public $foo;
}
class B extends A {
public $foo { get() { ...} }
}
Example 2:
class A {
public $foo { get() { ...} }
}
class B extends A {
public $foo;
}
One would expect that in both cases, instances of 'class B' would have a $foo
acting as declared in class B, shadowing the declaration from class A.
I think that the issue might be solved by an additional, not-yet-discussed and
very general extension, which is something I missed being able to do from time
to time: the possibility to declare a method (or property) in some class to be
explicitly NOT inherited. Syntactically, something like
class C {
public $bar;
public function twiddle();
}
class D extends C {
no public $bar;
no public function twiddle();
# might be followed by a different twiddle(), or $bar, implementation
}
The use case I have in mind, coming from the method side, is a subclass that
wants to use __call() for delegation AND needs to delegate to one or more
methods that are ordinarily plainly implemented in the base class.
What this feature would bring to the current discussion, is this possible
solution to your dilemma:
1) when a class declares a plain property public $foo, automatically apply
no function __getfoo(); no function setfoo(); (leaving out isset/unset for
clarity)
2) conversely, when a class declares public $foo { get() {...}}, or even
just declares one of the magic methods directly like public function
__getfoo() {} - automatically prepend / pretend a no public $foo;
cancelling a superclass property.
best regards
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Hi! Well, LSP is typically not applied to program semantics, since this is not a generally decidable problem. The only post-conditions that LSP normally enforces is type based, i.e. the covariance of the return type. Err, I'm not sure where you are taking this from, but LSP is certainly not limited to return types. See: https://en.wikipedia.org/wiki/Liskov_substitution_principle If you look at classic Square/Rectangle example, it's all about semantics and has nothing to do with types. Instead, LSP simply states that, given B : A, all objects of A can be substituted by objects of B while preserving the validity of the method calls on these objects, and the validity of their return values. This is guaranteed here: I would suggest at that point reading actual description of the LSP. You rendition of it is wrong. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Property Accessors v1.2 : Internal Accessor Method Visibility / Callability
Hi Stas, hi Etienne, let’s get practical and apply LSP to property accessors. Find below what I would read from the characteristics of LSP. Am 31.10.2012 um 20:46 schrieb Stas Malyshev smalys...@sugarcrm.com: [...] Instead, LSP simply states that, given B : A, all objects of A can be substituted by objects of B while preserving the validity of the method calls on these objects, and the validity of their return values. This is guaranteed here: Characteristics 1: Contravariance of method arguments in subtypes This applies to properties in so forth, that weaker requirements need to be allowed. This means: - Redeclaring a property without a specific type is OK (e.g. parent DateTime, children everything) - Redeclaring a property with a supertype is OK (e.g. parent MyDateTime, children DateTime) - Redeclaring a property that was read only as read-writable is OK in theory (it isn’t because of the history rule) - Redeclaring a property with as less visible is not OK (parent public, children protected) - Redeclaring a property with as more visible is OK (parent protected, children public) - Redeclaring a property as read-only is not OK (parent rw, children ro) Characteristics 2: Covariance of method return values in subtypes - For properties, this basically mirrors the rules from rules from characteristics 1 Characteristics 3: Preconditions cannot be strengthened: This is something we cannot and should not prevent in the language itself but it’s up to the programmer to do this correctly Characteristics 4: Postconditions cannot be weakened: See 3 Characterestics 5: History rule. See 3 cu, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ICU UConverter implementation for ext/intl
After the updates it looks really good, very handy functionality to have. On Tue, Oct 30, 2012 at 6:18 PM, Sara Golemon poll...@php.net wrote: With the exception of renaming the UConverter::UCNV_* constants to remove the UCNV_ prefix, I believe I've addressed the concerns thus far. ((Waiting to hear if anyone else wants to weigh in on the contants)) The RFC has been updated accordingly.+ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] ICU UConverter implementation for ext/intl
On 31 October 2012 06:18, Sara Golemon poll...@php.net wrote: With the exception of renaming the UConverter::UCNV_* constants to remove the UCNV_ prefix, I believe I've addressed the concerns thus far. ((Waiting to hear if anyone else wants to weigh in on the contants)) The RFC has been updated accordingly.+ I would say that unprefixing makes sense in general, particularly since that's what happens in other intl classes (such as Collator). Prefixing the callback reason constants with REASON_* seems like a good compromise there — as you said upthread, they are different to the other constants defined on UConverter. Beyond that, I think the type constants would do fine as direct UConverter constants (UConverter::UTF8, for instance, makes sense to me — in general, you're using a converter because you want to deal with encoding types). I'm +1 on the functionality in general. The thought of another encoding conversion API in PHP doesn't fill me with great joy given we already have mbstring and iconv, but it does provide features neither of those libraries provide: combined with the existing intl functionality and the ever-increasing need for internationalisation support, I'd like to think we might look at nudging intl towards being the usual way of providing that functionality in PHP. Thanks, Adam, who is apparently in a run-on sentence kind of mood today. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
