Hi,
On Wed, Oct 31, 2012 at 12:16 AM, Stas Malyshev 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
>>>
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 {
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
n
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 :
[...]
>> Instead, LSP simply states that, given B <: A, all objects of A can be
>> substituted by objects of
After the updates it looks really good, very handy functionality to have.
On Tue, Oct 30, 2012 at 6:18 PM, Sara Golemon 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 an
On 31 October 2012 06:18, Sara Golemon 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 accordin
