Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52406
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=ExSUxq3xb7EIStyE1CYZT4SD1K76xlpG1Z56xmLU6VkU5sAcqXCjlbpCu1g7i2OFGV
         fXcXww8zSDT7SIRjDT5R94ZTneLLQVbK9tdCHKIJQtauncukzNH5n0gybYxMYvl//svC
         S/IQ58bagGKXmkPD9p1RVXym7GL3SgbsYathY=
MIME-Version: 1.0
In-Reply-To: <BANLkTim-QFYq6Xcb+Y8h85DCpf1GQQ3EuQ@mail.gmail.com>
References: <BANLkTimkMTitkMkJ32B32cwYc_5qpLyRhA@mail.gmail.com>
	<1305570720.1344.535.camel@guybrush>
	<BANLkTi=ai-B0g0zwKbXOEH91r2i3ka5rAQ@mail.gmail.com>
	<BANLkTiku0mU94nf=TOQM5GNrLAvOY9Ky4A@mail.gmail.com>
	<BANLkTim-QFYq6Xcb+Y8h85DCpf1GQQ3EuQ@mail.gmail.com>
Date: Mon, 16 May 2011 15:28:58 -0400
Message-ID: <BANLkTi=r==iYmOuZNMAz0qivX4sCGfextg@mail.gmail.com>
To: Andrew Curioso <andrewcurioso@gmail.com>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	smalyshev@sugarcrm.com, internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: ircmaxell@gmail.com (Anthony Ferrara)

Well, if we follow that logic (which does make sense), then shouldn't
all magic methods be implicit?  So parent::__sleep/__call/__get/etc
would silently do the default if not defined?

On Mon, May 16, 2011 at 3:18 PM, Andrew Curioso <andrewcurioso@gmail.com> w=
rote:
> To play devil's advocate a bit:
>
> It's a special case. If it was really an undefined method then this is
> suddenly ambiguous:
> $foo =3D new Foo();
>
> If __construct() is undefined, what is being called in that case? By the
> same logic, that should
> throw an error as well.
>
> On the other hand, if __construct is presumed to be implicitly defined th=
en
> I think it makes
> logical sense for parent::__construct() to always succeed.
>
> Side note:
> If __construct is implicit then __destruct should also be.
>
>
>
>
>
>
>
> On Mon, May 16, 2011 at 3:10 PM, Anthony Ferrara <ircmaxell@gmail.com>
> wrote:
>>
>> Personally, I really don't care for something like this. =A0Would it be
>> caught by a __call declaration if one existed (since it is a call to
>> an undefined method)? =A0Would you expect it to?
>>
>> I'd rather see calls to non-existent methods generate a catachable
>> fatal error (rather than a hard fatal error that's currently thrown).
>> That way we can use an error exception to "catch" the fatal and
>> recover from it if necessary.
>>
>> But silently ignoring a called function, something just doesn't sit
>> right about that...
>>
>>
>>
>> On Mon, May 16, 2011 at 2:44 PM, Andrew Curioso <andrewcurioso@gmail.com=
>
>> wrote:
>> > I like that idea and I like that it works for userland classes as well=
.
>> >
>> > +1
>> >
>> > Do you think it should throw a warning, notice, or -- as you both
>> > suggested
>> > -- just silently succeed?
>> >
>> >
>> >
>> >
>> > 2011/5/16 Johannes Schl=FCter <johannes@schlueters.de>
>> >
>> >> Hi,
>> >>
>> >> I|d actuallz suggest a different option:
>> >>
>> >> If a parent constructor is called but doesn't exist the engine should
>> >> ignore this. The same goes for destructors.
>> >>
>> >> This solution would also work for userland classes.
>> >>
>> >> johannes
>> >>
>> >> On Mon, 2011-05-16 at 14:14 -0400, Andrew Curioso wrote:
>> >> > So, I ran across bug #54631
>> >> >
>> >> > A fatal error is thrown if you try to call parent::__construct() fr=
om
>> >> > a
>> >> > subclass
>> >> > of SplObjectStorage.
>> >> >
>> >> > I was going to close it as "expected behavior" since that is pretty
>> >> normal
>> >> > if the parent class doesn't implement __construct().
>> >> > Also, the docs don't list it as having a __construct() method.
>> >> >
>> >> > But then look at SplDoublyLinkedList (and a bunch of others). They
>> >> > are
>> >> > documented
>> >> > as having a __construct() method, yet it triggers a fatal error whe=
n
>> >> > you
>> >> try
>> >> > to call
>> >> > "parent::__construct()" from a subclass' constructor .
>> >> >
>> >> > So it seems to me that there are two possible solutions:
>> >> >
>> >> > - Update the docs to remove ::__construct() for classes that don't
>> >> > have
>> >> one.
>> >> > - Make sure __construct() is implemented in all SPL classes * and
>> >> > update
>> >> the
>> >> > docs.
>> >> >
>> >> > * Even if it is empty.
>> >> >
>> >> > What's everyone thinking?
>> >> >
>> >> > I'd be more than happy to add the constructors to the code where
>> >> > needed,
>> >> I
>> >> > just
>> >> > want to make sure that it is the right move first.
>> >> >
>> >> >
>> >> > - Andrew
>> >>
>> >>
>> >>
>> >> --
>> >> PHP Internals - PHP Runtime Development Mailing List
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >>
>> >
>
>
>
> --
> Andrew Curioso
>