Comments Inline On Mon, Nov 28, 2011 at 12:57 PM, Matthew Weier O'Phinney <weierophin...@php.net> wrote:
> This seems reasonable, but there are some pretty big drawbacks as well: > > * Type-hinting -- typically, a decorator should be able to be used > wherever the object it decorates is used. As such, if you simply > implement PHP\Decorator, type-hinting breaks. Well, not quite. Basically, what I was thinking of is this: 1. On instantiation, copy the class to a new anonymous class. 2. Set the parent of this anonymous class to the decorated object 3. Instantiate that new anonymous class. So basically it could satisfy all type-hints for the decorated object, since it's literally in the tree. I admit this is quite dirty, but the changes would be pretty localized to just the instantiation parts, since the other bits (type hinting) are resolved normally at runtime. > * It looks like it would require a particular constructor pattern, > which could be problematic. (You don't actually specify if the > constructor is the only means for injection, so I can give you the > benefit of the doubt here.) Well, the only thought I have would be to use the constructor. But if there are other options, great... > The primary problem is the first listed, though, and it's pretty big -- > I'd expect it would have large ramifications on Reflection, as well as > on various editors and IDEs to provide hinting. Yeah, that's a kick... And a pretty big one at that... > The problem with this is similar to that of Option 1 -- by using > __call(), you lose Reflection and hinting capabilities. Agree... > I _really_ like this option, to be honest. My only nitpick is that, like > Option 1, we need to flesh out how the object to be decorated is > injected into the decorator. Otherwise, this answers the problems I > raised in Option 1 and Option 2. Honestly, I could care less about that. Since it's a normal field, it could be done *after* instantiation (through a getter/setter), or even modified on the fly. The key would be to do one of two things. 1. Check on each access of the decorated members that it's an object and implements the correct method(s) - with the possible performance issues there. If not, you'd get a Fatal Error for call to member function on non-object if it didn't exist, and a new error if it did, but didn't implement the method (call to undefined method on object, not resolvable by __call)... 2. Check on "setting" of the property that it implements the proper methods. This would only happen once (when it's set) to boost performance. Then, the access check would just see if it was null (not set yet). So that means it should be pretty performant. But this involves the creation of a "magic property" type which would execute code (granted, c level code) on setting... Which may bring its own headaches... > in good OOP, you should be typehinting on > interfaces, not concrete implementations; following that logic, it's no > necessary. However, this breaks when decorating internal classes, where > there typically aren't interfaces. So my vote is that the hint be passed > on to the decorator. I have no idea how that would be handled, though. Well, perhaps we could edit the `instanceof` handler to check to see if it's a decorator object, and magically handle that as well. Although that could cause some very interesting behavior as well, so perhaps not the best. In other thoughts, perhaps just implement interfaces for the all of the core classes... That way at least the problem is "worked around" in practice... Thanks for the feedback!!! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
