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
