On 23 November 2011 18:37, Anthony Ferrara ircmax...@gmail.com wrote:
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but
Something else to consider:
Right now, Constructors are checked on interfaces. See the following
two examples:
http://codepad.viper-7.com/9IAGNP
http://codepad.viper-7.com/edokLi
So right now, interfaces are enforcing constructors fully (in 5.3).
Which makes more sense: Having abstract
Ralph:
From where I'm sitting, I can see a few sane alternatives (there may
be more, but here are the options I can see):
Option 1. Remove signature checking from constructors all together.
(I don't care for this, but whatever). Additionally, since it's not
enforced, perhaps an E_DEPRECATED or
Internals:
Time to summarize.
It is clear to me that internals is divided on this issue. I don't
think it's a large enough issue to drag on, even when I disagree with it
- both theoretically and in practice.
For most OO developer, putting ctors as an abstract or in an interface
would not
hi,
On Thu, Nov 17, 2011 at 10:12 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Hey All,
Concerning RC1, __construct() and https://wiki.php.net/rfc/prototype_checks
I think we need to round out this discussion on the __construct() signature
checking in 5.4. The current behavior (RC1)
On Thu, 17 Nov 2011, Ralph Schindler wrote:
That said, we really should consider removing this limitation from constructor
signature checking. Not only is it a BC break, it doesn't make sense in the
context of PHP.
I agree, we should not be having that check for constructors based on
the
I strongly disagree, this encourages bad practices. We could however
reduce the error level to warning.
On Fri, Nov 18, 2011 at 10:54 AM, Derick Rethans der...@php.net wrote:
On Thu, 17 Nov 2011, Ralph Schindler wrote:
That said, we really should consider removing this limitation from
Hey Pierre,
My perspective and expectations are framed by all sorts of existing
literature as well as the discussions on this list. It saddens me that
you did not address any of the points I've brought up. And, I simply
cannot tell what basis you have for your interpretation and opinion. It
Hey Ralph,
i think your argument on this is wrong. If we go your road:
1. Fact: PHP follows the LSP
2. Fact: The constructor is not part of the type, but a factory method.
3. Conclusion: constructors are not allowed to be part of the interface or
abstract classes.
Reversing the argument, by
Comments Inline
1) What we know and have been told is that PHP's signature
checking is governed by Liskov Substitution Principle. There are
many references to this in the list.
Except that signature checking is not needed for LSP to function. You
can write all of your code using duck typing
On Fri, Nov 18, 2011 at 6:40 PM, Ralph Schindler
ra...@ralphschindler.com wrote:
Hey Pierre,
My perspective and expectations are framed by all sorts of existing
literature as well as the discussions on this list. It saddens me that you
did not address any of the points I've brought up. And,
Hey All,
Concerning RC1, __construct() and https://wiki.php.net/rfc/prototype_checks
I think we need to round out this discussion on the __construct()
signature checking in 5.4. The current behavior (RC1) feels very wrong
with respect to PHP's class based, single inheritance, multiple
Honestly, I think __construct should behave like any other method when
specified abstract or via an interface.
I know you're thinking But it's not an LSP violation in the
constructor. But my assertion to that is that it's a violation of
the contract that the abstract method / interface defined.
Inline...
Honestly, I think __construct should behave like any other method when
specified abstract or via an interface.
Which is not fair to say because constructors are not like instance
methods, they are in fact special, and not just inside PHP (more on
that below).
I know you're
Some responses inline...
So, since PHP lets you do bad things in the first place (like have
constructors and static methods in interfaces, and abstract ctors in
abstract classes), we follow that up with another bad of breaking general
LSP expectations of how things work?
Isn't this trying
One point that was missed, that I'd like to reiterate is that:
Again, CTOR is not special b/c it's a PHP magic
method its special because it is shares qualities
of being a static method as well as an instance method.
That said, the constructor is not just another instance method.
16 matches
Mail list logo
