Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56404
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain ralphschindler.com from 209.85.161.170 cause and error)
Message-ID: <4EC69872.6060300@ralphschindler.com>
Date: Fri, 18 Nov 2011 11:40:02 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: internals <internals@lists.php.net>
References: <4EC578C9.4000408@ralphschindler.com> <CAEZPtU6pgOoEwexbFtBraBhgXJUCYk=Qhop1=EbHyfK-Ntfc9g@mail.gmail.com>
In-Reply-To: <CAEZPtU6pgOoEwexbFtBraBhgXJUCYk=Qhop1=EbHyfK-Ntfc9g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Changes to constructor signature checks
From: ralph@ralphschindler.com (Ralph Schindler)

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 
seems more like you're basing your interpretation on preference alone.

The facts are this:

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.

I've made my argument based on the LSP.

http://marc.info/?r=1&w=2&q=b&l=php-internals&s=lsp

2) "Abstract Constructors" do not exist in any other language, for all 
intents and purposes, it's something we've invented:

http://www.google.com/search?&q=%22abstract+constructor%22

That's fine, so now the question is, how does this thing we've invented 
play in with our current implementation of a class based object model 
and how does it meet developer preexisting expectations?

3) In places that have no formal expectation and understanding in other 
programming languages, we've OFTEN favored *looseness over strictness*

Even you Pierre, once promoted "looseness"
http://news.php.net/php.internals/25089 (Pierre)

4) We should meet everyone's existing expectations, Rasmus talks about this:

http://news.php.net/php.internals/25090 (Rasmus)

and this is the general expectations:

http://www.google.com/search?q=constructor+liskov

http://stackoverflow.com/questions/5490824/should-constructors-comply-with-the-liskov-substitution-principle

> <?php
>
> class A {
> 	function __construct($a, $b) {
> 	}
> }
>
> class B  extends A{
> 	function __construct($a) {
> 	}
> }
>
>
> works.
>
> While the following does not:
>
> Abstract class A {
> 	abstract function __construct($a, $b);
> }
>
> class B extends A{
> 	function __construct($a) {
> 	}
> }


Which makes no sense b/c this does work:

abstract class A {
     abstract public function __construct($one, $two, $three);
}
class C extends A {
     public function __construct($one, $two, $three) {}
}
class D extends C {
     public function __construct($foo) {}
}

I assume this is b/c only one ->ce_parent is checked for "definition 
correctness" or whatever this new feature is we're calling ... but more 
to the point, do we really want to recurse every parent definition 
looking for an abstract __construct() and checking the signature at runtime?

> does not and it is per definition correct. Abstract defines the
> signature and ensures that the signature are 100% the same.

Where do you get your foundational basis for this?  What rules outside 
of the LSP are we looking at to make this determination?

And, can you honestly say that of the global community of developers, 
this is the expected outcome?

> We had a long discussion about that a couple of months ago. The main
> disagreement was about the interpretation of the definition of
> abstract. Abstract clearly talks about signature matching, as I (and
> quite a lot of other) read it.

According to the RFC (https://wiki.php.net/rfc/prototype_checks) a 
consensus was never reached - and more discussion was needed (which as 
of the date of the RFC and timestamps in the mailing list, has not 
happened).

-ralph