Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52417
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:mime-version:content-type:from:in-reply-to:date:cc
         :message-id:references:to:x-mailer;
        b=mcrvWAOlngmUd/1pDc2cT7+5OUPe82y/MxmTxiIkwutPsJTYVIPz/47tMSpLujDWyw
         qYSSM1tQ5fyA7uk3iZVZVbDLzgjL5Fq/wMRTkyfT1Bpal0fE9JZeMc0IcQV9lezvVi4j
         NWQU86rJ3G2mNwQZA3lCSjkP5YK3x828S8Ykk=
Mime-Version: 1.0 (Apple Message framework v1227)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F803FFF6-8A08-49BC-A136-A1800D600F89"
In-Reply-To: <20110516212511.GA13139@crousti>
Date: Tue, 17 May 2011 02:22:30 +0200
Cc: internals@lists.php.net
Message-ID: <7FCA24D2-64A9-4E8C-8AE9-8934A5B074E6@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> <4DD17ECD.4070505@sugarcrm.com> <BANLkTikBj=bh+R9gntDMbdg8a0Y2FnJrmA@mail.gmail.com> <20110516212511.GA13139@crousti>
To: Etienne Kneuss <colder@php.net>
Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL
From: benjamin.dubois@gmail.com (Benjamin Dubois)

--Apple-Mail=_F803FFF6-8A08-49BC-A136-A1800D600F89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Hi,

Why not make all objects (maybe implicitly) extend a single root object, =
containing just skeleton ctor/dtor and implemented in the engine ?

I don't know if it is actually  possible in PHP, but that works for =
several other languages (java, objC - in that case, the root object is =
explicit-, C# AFAR)

This would also bypass the error-level debate (no error would be thrown)



--
Regards,
Benjamin Dubois



Le 16 mai 2011 =E0 23:25, Etienne Kneuss a =E9crit :

> Hi,
>=20
> On May 16 16:52:08, Andrew Curioso wrote:
>> Well, that wasn't where I was expecting that thread to go, but to =
wrap it up
>> what do you think...
>> Is it too late to put this on the 5.4 roadmap for consideration?
>>=20
>> I'm assuming just the implicit ctor and dtor. Not all magic methods =
(not
>> now, at least).
>>=20
>> With your OK, Stas, I'd like to write up an RFC and put it on the =
Wiki.
>>=20
>> - Andrew
>=20
> The main problem with internal classes and ctors is that constructor
> code can be placed at object init instead of in the actual ctor =
method.
> It is actually safer to place it at object init, because then that =
code
> is always executed and thus the internal object is not in a half
> initialized state if the user overwrites the constructor and doesn't
> call the parent.
>=20
> I'd rather have ctors/dtors explicitely defined in SPL. If they are
> documented to exist, they should be explicitely defined. We can define
> such NOOP methods globally, so that it is easy for internal classes to =
add
> them.
>=20
> As far as implicitly ignore of the constructor, I believe we have =
enough
> magic regarding ctors/dtors in the engine as it is.
>=20
> Best,
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>=20


--Apple-Mail=_F803FFF6-8A08-49BC-A136-A1800D600F89--