Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52408
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.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;
        b=syTQeEUU3mFno5tsOCSKs1mEJAzVSVjPLGX9TThxs9+DyatZ3eeZRAUVrO25eaVu37
         lbt1l9o2p9QlwuiIym5xohLu4BHxJMGDjhtNt/XshZmYUJ2XkHAiL1/15nvHKDg0N0rC
         2l+7NBH+oABrBw3zlOMwmrHmGC7jyDEz8978o=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=r==iYmOuZNMAz0qivX4sCGfextg@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>
	<BANLkTi=r==iYmOuZNMAz0qivX4sCGfextg@mail.gmail.com>
Date: Mon, 16 May 2011 15:43:15 -0400
Message-ID: <BANLkTin-Fxy5QjTrQqc2fvNxt-F26kD+Gw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	smalyshev@sugarcrm.com, internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf307f34a2d0174104a369ddb5
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: andrewcurioso@gmail.com (Andrew Curioso)

--20cf307f34a2d0174104a369ddb5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

That is a whole other can of worms. Whereas __construct() and __destruct()
can do nothing and are probably pretty trivial to get working, some other
methods aren't so clear cut.

Example: __sleep() would have to return an array of member variables so
that it does what is expected when called by the user. Like this...

...
public function __sleep()
{
  return array_merge( parent::__sleep(), array( "foo", "bar" ) );
}
...

My only point being. I like the idea in principal but implementing it for
all magic
methods could become a somewhat major undertaking.




On Mon, May 16, 2011 at 3:28 PM, Anthony Ferrara <ircmaxell@gmail.com>wrote=
:

> 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>
> wrote:
> > 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 th=
e
> > same logic, that should
> > throw an error as well.
> >
> > On the other hand, if __construct is presumed to be implicitly defined
> then
> > 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.  Would it be
> >> caught by a __call declaration if one existed (since it is a call to
> >> an undefined method)?  Would 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 shou=
ld
> >> >> 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()
> from
> >> >> > a
> >> >> > subclass
> >> >> > of SplObjectStorage.
> >> >> >
> >> >> > I was going to close it as "expected behavior" since that is pret=
ty
> >> >> 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). The=
y
> >> >> > are
> >> >> > documented
> >> >> > as having a __construct() method, yet it triggers a fatal error
> when
> >> >> > 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
> >
>



--=20
Andrew Curioso

--20cf307f34a2d0174104a369ddb5--