Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67591
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain l-i-e.com designates 67.139.134.202 as permitted sender)
Message-ID: <b1b6c3ded322f7a9dba117f0f4c90473.squirrel@www.l-i-e.com>
In-Reply-To: <6b642a96e673c29dbaf2f239be15f7f6.squirrel@www.l-i-e.com>
References: <6b642a96e673c29dbaf2f239be15f7f6.squirrel@www.l-i-e.com>
Date: Wed, 29 May 2013 20:13:52 -0500
To: internals@lists.php.net
User-Agent: SquirrelMail/1.4.21 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] Cannot call constructor
From: ceo@l-i-e.com ("Richard Lynch")

First, thanks for all the comments!

Responding in-line to myself to address everything so far in this thread:

On Thu, May 23, 2013 4:24 pm, Richard Lynch wrote:
> Consider this common scenario:
>
> I use some OOP library, that is a "black box" and I like it that way.

This was a made-up scenario.

Well, somewhat...

In my experience, this sort of thing usually happens in the corporate
environment with Jr. Programmer, rather than in publicly-released
libraries.

Educating Jr. Programmer regarding documentation needs to happen and
will happen, but it will probably be out-of-band from using their
code.

> if (method_exists(get_parent_class(), '__construct'))
> parent::__construct();

99% of the time, I need to call their constructor before mine to
initialize stuff.

I'm very pragmatic.

If PHP had default __construct, and in the absence of [decent] docs
for the parent, I'm going to call the parent constructor first and
pray.

I thought all PHP user-land class were rooted in stdClass. The class
functions that display hierarchy obscure that, but there it's there
under the hood.

If so, adding the magic anti-pattern methods to stdClass would be
easy, right?

Extensions that return PHP objects should get the "free ride" from
stdClass, I would expect.

The sample init() pattern or whatever from Etienne made my eyes
un-focus in the first couple lines.
I'm not saying it's not the better pattern, or even that what I
propose isn't an anti-pattern.
Just it was way too complicated for what I need 99% of the time.
I'm sure if I *needed* that particular pattern's properties it would
make a whole lot more sense.

My thoughts on which magic methods [don't] fit this treatment:

DO FIT
__construct: 99% I let them init their stuff, and I init mine
__destruct: I tear down my stuff, and call the parent
__toString: I would imagine children "tacking on"
(actually, I think parent::__toString being safe might be baked in
already, as all classes have a toString, right?...)
__call*: Parent first, do my stuff, usually return parent result
__invoke? Never used it, don't like it, basing on description

DO NOT FIT
__sleep
__wakeup
__get
__set
__isset
__set_state Already effectively calls all descendants if the first
note is correct...
__clone Already has an :after method __done() to deal with this

I'm not particularly strongly for or against any of them except
__construct __destruct

Well, __set_state and __clone pretty much have to be the NOT FIT pile,
as far as I can see.

Again, I'm VERY pragmatic. The base object having __construct and
__destruct so I can call them in FIFO/LIFO order covers 99% of the use
cases.

If I was writing an RFC today, and I'm not until there is a little
more discussion on-list, I would explicitly include only ctor/dtor in
it as a trial, and leave the rest for "later". Or "never" if that's
the way it pans out.