Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56380
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EC5924C.8000605@ralphschindler.com>
References: <4EC578C9.4000408@ralphschindler.com>
	<CAAyV7nHEdvWm8QhYoya2wKhA5T67QAy9MQiMc93TRhGt6tgmFg@mail.gmail.com>
	<4EC5924C.8000605@ralphschindler.com>
Date: Thu, 17 Nov 2011 23:08:33 -0500
Message-ID: <CAAyV7nFoy2XZAcQ+MMc6yLiOY91oKr5Ng9=GK3S++1fgczFNkA@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)

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 gener=
al
> LSP expectations of how things work?
>
> Isn't this trying to make two wrongs make a right?

That's why I tossed out the concept of raising a notice or E_STRICT
error if a constructor is used in an interface/declared abstract.

> The rest of the __magic() methods by and large are purely instance method=
s
> (part of the instance API). =A0Having them inside an interface is complet=
ely
> logical. =A0(BTW, these methods can be considered engine-level/promoted d=
uck
> typing since you don't have to implement an interface for them to do what
> they do, but that's not important here)

Well, that's true.  However, with the exception of invoke and
toString, the same functionality can be provided by the class.  __call
can be avoided by hard-coding the method (well, within reason).
__get, __set and __isset can be avoided by making the members public.
__sleep can be avoided by using the Serializable interface.  That's
why I'm pushing them in to that discussion.  It's an implementation
detail that's not really associated with the contract provided.  That
was my point (which is really not 100% related to the constructor, but
is related in passing)...

> Lets look at that, the proxy pattern that is. =A0This is no longer valid =
usage
> in 5.4:

That's not a proxy.  That's a Bridge or Adapter pattern.  Proxy
usually delays instantiation until first call (See
http://sourcemaking.com/design_patterns/proxy ).  So in your example,
the proxy class would be:

class ProxyNamedAgedPerson extends NamedAgedPerson {
   public $proxy =3D null;
   protected $proxyClass =3D '';
   public function __construct($proxyClass)
   {
       $this->proxyClass =3D $proxyClass;
   }
   public function setAge($age)
   {
       if (empty($this->proxy)) {
           $class =3D $this->proxyClass;
           $this->proxy =3D new $class;
       }
       $this->proxy->age =3D $age;
   }
}

The usage you gave would make no sense for this discussion (the
difference in constructor implementations).  However, in the proxy
example above, it makes a significant difference.  If you didn't put
it in the abstract class/interface, you could get a fatal on
instantiation.  Not saying it's hugely significant, but it's a valid
use-case.

> First, if I consume a system that has practiced this abstract ctor in
> abstract class thing, I cannot create valid subtypes on my own in PHP 5.4=
.
> =A0The above will throw an E_FATAL.

As it should, since you have a contract expecting what the subtype
doesn't implement.

> Secondly, (AND WORSE) is that by simply removing the abstract keyword fro=
m
> the abstract classes __construct(), I get completely different behavior,
> everything works without E_FATAL.

You should get different behavior.  Without Abstract, you no longer
have a contract, so there's nothing to be enforced.  Saying that's a
problem is like saying "But my code works if I remove the private
keyword from the method declaration".  It changes the meaning of the
construct significantly...  (whether abstract/inferface constructors
should be allowed is another story, but if it is, you should get the
fatal)...

> Thirdly, (EVEN WORSE!), is that if I comment out the $name, $age part of =
the
> NamedAgedPerson (see: COMMENT OUT HERE above), no E_FATAL is thrown on
> *grandchildren* who violate this abstract ctor.

Now that's a huge problem.  All descendants should be forced to the
same contract...  I'd classify that as a bug...

> So, if we choose to do this wrong+wrong=3D~right thing, we should at leas=
t do
> it correctly/consistently all the way through the inheritance type
> hierarchy. =A0Don't you think?

Agree

> Of course, this argument is mostly pedantic to be honest, as I'd be
> instructing people to never attempt to put abstract ctors in abstract
> classes. =A0I won't be doing that either, but, the argument is largely th=
at
> the engine shouldn't be doing these kind of things to begin off with.

I don't know.  In PHP, a method is a method.  Sure, some are called
specially by the engine, but why should the constructor be any
difference (conceptually).  Sure, you usually type-hint against
interfaces after construction, but you clearly don't have to.  You
could argue if it belongs or not, and I think that's worth talking
about.  But if you want consistency, it should either apply to all
engine-called magic methods or none of them.  The two cases above
(__toString and __invoke) could be solved with a pair of interfaces
(stringable and invokable possibly) to use instead of the methods.
Then simply remove all magic methods from interfaces...  Honestly, I
don't feel strongly either way (keep all or remove all), but I think
it should be one or the other, not both...

> Also, I'd has to see this kind of decision impacting future decisions (li=
ke
> this) b/c it was "ratified" in 5.4.

Again, no argument at all.

Anthony