Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56376
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EC578C9.4000408@ralphschindler.com>
References: <4EC578C9.4000408@ralphschindler.com>
Date: Thu, 17 Nov 2011 17:14:06 -0500
Message-ID: <CAAyV7nHEdvWm8QhYoya2wKhA5T67QAy9MQiMc93TRhGt6tgmFg@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Changes to constructor signature checks
From: ircmaxell@gmail.com (Anthony Ferrara)

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.  If it's a
violation of contract, I would expect to get a fatal error.  After
all, that's what a contract is for if not to enforce.

Now, you could make the argument that it's impossible to enforce a
contract (via type-hinting/instanceof) since there's no object at that
point.  So the contract isn't "signed".  And that's the *only* reason
that I could understand for wanting to change it from a fatal error to
ignored.

However, if that's taken, then I would expect to be notified that
constructors are not enforced by the interface/abstract method.
Perhaps raise a notice (or E_STRICT) in the interface on compile time
that "__construct is not enforced by interfaces"...

Additionally, what about other magic methods?  Should they be handled
separately?  I could understand a contract to enforce __invoke and
__toString, but what about the rest?  Should they be specifiable in
contract form (get/set/call/etc)?

So, actually I'm not so sure on that myself.  The Only use case I can
think of I've used here:
https://github.com/ircmaxell/PHP-CryptLib/blob/master/lib/CryptLib/Core/Abs=
tractFactory.php#L51

Basically, it's an abstract factory that checks if a class name
implements an interface before it will "register" the class.  This is
useful for implementing proxy patterns and the such.  So we don't
actually instantiate until later.  But we want to be sure that when we
do, we'll have the proper class implementing the proper interface.
Since the factory will call `new` later, it needs to know the
constructor is valid.  So declaring the constructor in the interface
actually makes sense there...

So, my opinion is that either all magic methods (with the possible
exception of __toString and __invoke) should be excluded from
interface requirements, or none should.  Either way is fine with me,
but they should be consistent.

And I do lean on the side that the contract is the contract, and if
you change (overload) a method, you're breaking the contract.  And if
you specify the constructor in the contract (you don't have to), you
should be bound to that contract...

So I think 5.4's behavior is the proper one.  I won't be upset if it
changes, but if it does I think the rest of the magic methods (two
mentioned withstanding) should change as well...

Just my $0.02...

Anthony

On Thu, Nov 17, 2011 at 4:12 PM, Ralph Schindler
<ralph@ralphschindler.com> wrote:
> Hey All,
>
> Concerning RC1, __construct() and https://wiki.php.net/rfc/prototype_chec=
ks
>
> I think we need to round out this discussion on the __construct() signatu=
re
> checking in 5.4. =A0The current behavior (RC1) feels very wrong with resp=
ect
> to PHP's class based, single inheritance, multiple interface, no method
> overloading, allowed method-overriding nature.
>
> Constructors themselves, specifically in PHP, are not explicitly statical=
ly
> marked, but are "special" (even though they are part of the instance API,
> and are callable- we'll consider this an implementation detail). =A0In
> general, constructor signatures have never been (and rightfully so) gover=
ned
> by the LSP. =A0Why? For a few reasons:
>
> =A01) before calling new(), you actually don't have a subtype (yet)- the
> subtype is a *product* of new()
>
> =A02) when you call new(), you know the exact subtype you're dealing with=
.
>
> =A03) only subtypes who implement or override __construct() can know how =
to
> prepare a stateful subtype. =A0In other words, parents can't know how to
> create subtypes who implement __construct() and subtypes shouldn't be
> concerned with the implementation details of how a parent creates types w=
hen
> a subtype has overridden __construct();
>
> =A04) LSP deals with behaviors and expectations of types (read: objects),
> since the constructor is generally considered "static" in nature, a form =
of
> factory specific to the type its defined within, and since in PHP you can=
't
> do (SomeClass instanceof SomeType) and since (is_a('SomeClass', 'SomeType=
')
> doesn't make much sense in the context of classes), the constructor is no=
t
> subject to instance "behavior" rules.
>
> In general, developers shouldn't be putting abstract constructors inside =
an
> abstract class nor should they be putting constructors inside interfaces-
> this is a well accepted bad practice. =A0(Neither c# or java allow this- =
of
> course they do have the ability to overload methods in classes for the
> record. =A0In fact, static methods are not allowed either.)
>
> That said, we really should consider removing this limitation from
> constructor signature checking. =A0Not only is it a BC break, it doesn't =
make
> sense in the context of PHP.
>
> Thoughts?
>
> Thanks,
> Ralph Schindler
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>