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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
