Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56574
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKUjMCVc1DPUAHXPQzy1R9pULaGurhPynLROPtiiu9amZ6rA9w@mail.gmail.com>
References: <4EC578C9.4000408@ralphschindler.com>
	<alpine.DEB.2.02.1111180954250.5937@whisky>
	<CAEZPtU4FHG_PTezL+LbweftuRu4248Rgmo2HJLtSBFV=nNo9Lg@mail.gmail.com>
	<4ECD3A9E.7090105@ralphschindler.com>
	<CAAyV7nGiTSohi456=jPEqm8O4jCBLkGCRmTkJtM8iPH1Oc+D=Q@mail.gmail.com>
	<CAKUjMCVc1DPUAHXPQzy1R9pULaGurhPynLROPtiiu9amZ6rA9w@mail.gmail.com>
Date: Thu, 24 Nov 2011 07:32:49 -0500
Message-ID: <CAAyV7nFgPvkfKob1ww5gOv4brHCsy00gcnb3Pg2ZQ0uPH--uOQ@mail.gmail.com>
To: RQuadling@gmail.com
Cc: Ralph Schindler <ralph@ralphschindler.com>, Pierre Joye <pierre.php@gmail.com>, 
	Derick Rethans <derick@php.net>, 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)

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 behaving the same as
the interface declaration (to grand-children, etc), or having abstract
declarations behave differently and ignoring abstract constructors?

My vote is for consistency (since the concept between abstract methods
and interface methods is very similar)...

Anthony

On Thu, Nov 24, 2011 at 5:48 AM, Richard Quadling <rquadling@gmail.com> wro=
te:
> On 23 November 2011 18:37, Anthony Ferrara <ircmaxell@gmail.com> 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. =A0Remove signature checking from constructors all together.
>> (I don't care for this, but whatever). =A0Additionally, since it's not
>> enforced, perhaps an E_DEPRECATED or E_STRICT error should be raised
>> on definition, as it is superfluous...
>>
>> Option 2. =A0Fix grandchild signature checking to be inline for how
>> signatures work with other methods.
>>
>> Personally, I think option 2 is the better one. =A0I see it being odd
>> and inconsistent that all methods work one way, and constructors work
>> differently. =A0But that's just my feeling (and I know others disagree
>> there).
>>
>> And please don't reduce the error level of a signature change (as it
>> would introduce even more inconsistency)...
>>
>> Just my $0.02...
>>
>> Anthony
>>
>> On Wed, Nov 23, 2011 at 1:25 PM, Ralph Schindler
>> <ralph@ralphschindler.com> wrote:
>>> Internals:
>>>
>>> Time to summarize.
>>>
>>> It is clear to me that internals is divided on this issue. =A0I don't t=
hink
>>> it's a large enough issue to drag on, even when I disagree with it - bo=
th
>>> theoretically and in practice.
>>>
>>> For most OO developer, putting ctors as an abstract or in an interface =
would
>>> not happen anyway, so this does not affect them.
>>>
>>> ** The current change represents a minor break in BC, that should be no=
ted
>>> in the manual. **
>>>
>>> Also, a decision needs to be made on what to do with grandchildren. =A0=
As I
>>> mentioned, the following produces no E_FATAL and no warnings:
>>>
>>> =A0abstract class A { =A0abstract public function __construct($a, $b); =
}
>>> =A0class B extends A { public function __construct($a, $b) {} }
>>> =A0class C extends B { public function __construct(ArrayObject $d) {}
>>>
>>> While this is correct behavior to me (ability for concrete to use its o=
wn
>>> ctor), using the *current logic* strict signature checking enforced fro=
m an
>>> abstract, then the above is also wrong.
>>>
>>> ** Can we decide what to do with that situation? **
>>>
>>> On 11/18/11 5:05 AM, Pierre Joye wrote:
>>>>
>>>> I strongly disagree, this encourages bad practices. We could however
>>>> reduce the error level to warning.
>>>
>>> I think this is a sufficient compromise- I don't see anything E_FATAL a=
bout
>>> a signature change in ctors (I actually see nothing wrong with it, but =
it's
>>> clear the community is divided there).
>>>
>>> ** Can we make that change? **
>>>
>>>
>>> Thanks,
>>> -ralph
>
> What is the normal way for userland developers to learn about
> constructors? Do they know about LSP? If they do, does it apply to
> constructors?
>
> A comment on StackOverflow [1]
>
> "At its heart LSP is about interfaces and contracts as well as how to
> decided when to extend a class vs. use another strategy such as
> composition to achieve your goal."
>
> I am self taught. It was always my understanding that the constructor
> was special in that it is, essentially, a magic method that can only
> respond to the new keyword. Being able to call the constructor
> directly, ..., that does feel a little odd as I can't actually
> construct a new instance that way.
> Using an interface to enforce the sig is fine. That's the exact nature
> of an interface, to enforce the contract by design and if the
> StackOverflow comment is accurate, then my understanding of interfaces
> is fine with regard to LSP.
>
> An abstract class, by its very nature is not formed. It isn't a
> contract. It is an idea and the concrete doesn't need to fit
> perfectly. OK. There is some things that are fixed, method signatures
> most accept the parameters defined in the subclass but can add more
> (as I understand things).
>
> But is the signature of the constructor in an abstract class to be
> enforced? I feel that it shouldn't be. It is a special method.
>
> WikiPedia [2] has an article on Constructor Overloading. It says
> "Constructors, used to create instances of an object, may also be
> overloaded in some object oriented programming languages.". OK, so
> WikiPedia may have a different opinion tomorrow.
>
> Whilst we don't support overloading in the same way (I think we can
> simulate it with __call() easily enough with ReflectionParameter being
> my friend here maybe).
>
> We, DO, provide the tools to allow overloading and non LSP coding
> practises. Is it a great leap to also allow the same flexibility with
> constructors?
>
> Regards,
>
> Richard Quadling.
>
> [1] http://stackoverflow.com/questions/56860/what-is-the-liskov-substitut=
ion-principle
> [2] http://en.wikipedia.org/wiki/Constructor_overloading#Constructor_over=
loading
> --
> Richard Quadling
> Twitter : EE : Zend : PHPDoc : Fantasy Shopper
> @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea=A0:
> fan.sh/6/370
>