Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56407
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EC69872.6060300@ralphschindler.com>
References: <4EC578C9.4000408@ralphschindler.com>
	<CAEZPtU6pgOoEwexbFtBraBhgXJUCYk=Qhop1=EbHyfK-Ntfc9g@mail.gmail.com>
	<4EC69872.6060300@ralphschindler.com>
Date: Fri, 18 Nov 2011 13:40:25 -0500
Message-ID: <CAAyV7nFfsWD8gkRPhNmp=ubOEWOhDbKzjDWqfZvfkqzovRWKhw@mail.gmail.com>
To: Ralph Schindler <ralph@ralphschindler.com>
Cc: Pierre Joye <pierre.php@gmail.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] Changes to constructor signature checks
From: ircmaxell@gmail.com (Anthony Ferrara)

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 without interfaces and
abide by LSP 100%.  In fact, you can do things like override a
function with a signature of foo($bar, $baz) with one of foo(), and
STILL have it be LSP compliant due to the dynamic ways PHP handles
arguments.

So LSP may be a motivator, but ti's not the reason.  What could be a
reason is to enable Design-By-Contract style development where the
interface is the defined contract.  Now since PHP doesn't support
dynamic introspection of the method at run-time, the signature is the
only way of determining if the method abides by the contract.

> 2) "Abstract Constructors" do not exist in any other language, for all
> intents and purposes, it's something we've invented:

True, however in most other language constructors are not actual
methods, but a pseudo method on the object that can't be called
explicitly aside form `new` (obviously not true for all, but most of
the big ones).

Additionally, PHP is quite different from a fair bit of other
languages in that you can do things like `new $class()`.  Java and C#
don't allow this.  So to them, it's not an LSP violation or even
necessary to have it abstract since you **know** the subtype your
instantiating.  However, in PHP that's not true.  You can do
variable-class-names.  So that eliminates the assertion that you
**know** the subtype your instantiating.  You don't, and you can't.
But you can check the interface on the class name in the variable
(which is what I did in that library I posted before).    So by
specifying the constructor as abstract/interface is one way of adding
safety when you accept a class name and do dynamic instantiation...

> 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?

There are two ways to see it.  Either constructors are really just a
method that's called by the engine, or they are not a method and are
special "blocks" which are not callable in userland.  However, since I
can legally call `$obj->__construct()`, I think it's pretty safe to
say that it's considered a real method in PHP.  And real methods are
specifiable in abstract/interfaces.

So really we didn't invent anything at all.  The "invention" is that
the constructor is a method (with all the caveats that apply)...

> 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)

Well, looseness over strictness unless strictness is specified.  Look
at the class based type hints.  That's strict.  Interfaces and
signature checking are absolutely strict.  Considering that the use is
optional, and the construct that's using it is normally associated
with strictness that it's ok that the constructor check is strict...



Again, I'm not arguing the design decision of putting a constructor in
an interface.  I'm talking about what would be expected if you did, or
more specifically if you're allowed to...