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 methods
On 23 November 2011 18:37, Anthony Ferrara 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 whatever). Add
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 h
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
On Fri, Nov 18, 2011 at 6:40 PM, Ralph Schindler
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, I simply cannot
> t
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 typi
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 intr
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
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 wrote:
> On Thu, 17 Nov 2011, Ralph Schindler wrote:
>
>> That said, we really should consider removing this limitation from
>> constructor
>>
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
hi,
On Thu, Nov 17, 2011 at 10:12 PM, Ralph Schindler
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) feels very wrong w
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 metho
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 t
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 thi
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.
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
interf
16 matches
Mail list logo