> I use some OOP library, that is a "black box" and I like it that way.
Hmm, there's "well-documented, change-controlled, trustable API that you shouldn't try to work around" and then there's "black box." I'm not sure the latter ever sounds like a good thing... I've always used it as a bad word. > Suddenly my code doesn't work. Maybe the resource is only needed under > certain conditions. So their __construct doesn't get called, but > nothing bad happens until the circumstances where they need the > __construct called. If their __construct suddenly becomes mandatory, they are deprecating something they (I presume explicitly) supported in the past: ctor overrides without call super. So either they put this in giant blinking text in their UPDATING file and you missed it, or they broke backward compatibility and didn't know it or didn't care. If I were faced with their situation, I'd make the ctor final to make damn sure you realized something was wrong. Then I would say overriding __construct is no longer supported because continuing to support it means mandating call super, which is an impossible contract for the language (this anguage) to enforce. I would abstract the whole thing out to an initChild() type pattern and so on. If you have to change your code, them's the breaks, as long as they give a clear path. I don't think the solution is to work around such mistakes on the part of a lib developer by silencing (?) calls to a nonexistent method _in addition to_ mandating call super -- IMO, that's even smellier than call super on its own. Why not add auto-super contracts to PHP instead (which would include skipping nonexistent super methods)? Making the undefined method error catchable instead of fatal I agree with, though. More like the more catchable world of Reflection. -- Sandy -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
