Page 2 of 2
Posted: Fri Jun 29, 2007 8:37 pm
by dbevfat
I agree with arborint here. Inheritance can be useful but mustn't be abused. As a rule of a thumb, inheritance relationship should be looked upon as a is a relation, otherwise it's probably just abusing inheritance for convenience. With exceptions, of course.
Can't really say, because I don't know your exact goals, but I've done it quite a lot a while ago and all I got was a little convenience for a price of a very static and fragile hierarchy and inflexibility.
Posted: Mon Jul 02, 2007 8:44 pm
by Begby
I use a base object in PHP5 but only to override __get() and __set() and to have those throw an exception whenever they are called as a hillbilly way of keeping myself from calling non-declared object properties. I can see how it might be useful for testing though in some cases.
Posted: Mon Jul 02, 2007 9:42 pm
by Christopher
I can understand why you might want to do something like that. Only I would probably call that class Propertied or ValueObject or something, rather than Base or Object. And I'd probably only use it for classes that actually needed that functionality.
Posted: Mon Jul 02, 2007 11:57 pm
by feyd
DNAObject is primarily a value object with specialized property lists that allow for more control on the access of properties than merely public, protected and private provide. Most of the objects, but not all, inherit from this class. It uses finalized __get and __set and __call methods to assert this control. The plan is to support plugins to these to provide for an avenue of augmenting the execution further, if need be.
Posted: Tue Jul 03, 2007 6:07 am
by superdezign
Uh-oh. feyd's doing it too.
The base object "Object" is soo Java/JavaScript. The magic methods already "imply" a base object of sorts, so why bother making a base object out of a another base object?
Posted: Tue Jul 03, 2007 7:12 am
by anjanesh
The base object "Object" is soo Java/JavaScript
- so is .NET.\
PHP supports OOP but is not built-on on OOP.
Posted: Tue Jul 03, 2007 10:31 am
by Ollie Saunders
feyd wrote:DNAObject is primarily a value object with specialized property lists that allow for more control on the access of properties than merely public, protected and private provide. Most of the objects, but not all, inherit from this class. It uses finalized __get and __set and __call methods to assert this control. The plan is to support plugins to these to provide for an avenue of augmenting the execution further, if need be.
You spoke about this a long time ago and I thought it was a brilliant idea and then mused over it for a number of months deciding not to do it for several reasons:
- Non-obvious low level behaviour that has to be explained to programmers to have any chance of understand what is going on in the code base
- Reflection is difficult/complicated
- Problems with generating documentation
- Risk that functionality will be moderately inappropriate to some classes. This is of course true with any inheritance but considering how widespread the usage of this is the risk is greater. If you choose not to use it on some classes than behaviour becomes yet more unpredictable and non-obvious.
- More code to maintain, temptation to tweak having far reaching implications.
- Performance hit
- One, indeed most, can write perfectly good code without it
Posted: Tue Jul 03, 2007 11:52 am
by Christopher
Ole give an excellent summary of this issue. Obviously people create base objects in PHP and have done so since objects were introduced. However, because some people have very specific preferences on object behavior does not mean that in general it is a good practice in PHP. I have encountered many more programmers and frameworks that have had to undo this decisioin than add it.
Posted: Tue Jul 03, 2007 3:40 pm
by feyd
ole wrote:Non-obvious low level behaviour that has to be explained to programmers to have any chance of understand what is going on in the code base
It's fairly straight forward in my code base. If you're accepting of the default property permissions it's a simple matter of initializing the property in the constructor. Specifying alternates permissions isn't too difficult either in that you create a permissions data object filling the bits as needed and pass it to DNAObject's property factory.
ole wrote:Reflection is difficult/complicated
Using the reflection system, yes, but these properties aren't engineered for reflection, they are mostly geared toward renderable or highly interactive objects.
ole wrote:Problems with generating documentation
I haven't had any problems. Care to elaborate?
ole wrote:Risk that functionality will be moderately inappropriate to some classes. This is of course true with any inheritance but considering how widespread the usage of this is the risk is greater. If you choose not to use it on some classes than behaviour becomes yet more unpredictable and non-obvious.
The classes that do not inherit from this are, for the most part, inaccessible to the other programmers due to their low-level location in the layering. They can interact with them if they really choose, but they do so at their own risk.
ole wrote:More code to maintain, temptation to tweak having far reaching implications.
Not for this system.
ole wrote:Performance hit
I'll agree, there is a performance hit, but that's what programmers get when they choose to sidestep accessors and mutators.
ole wrote:One, indeed most, can write perfectly good code without it
The system is intended to keep silly mistakes from happening, not by highly experienced programmers, but the ones interacting with the system, who are more often than not, inexperienced.
Posted: Fri Jul 06, 2007 5:58 am
by anjanesh
ole - combining these classes into a a
phar solves a lot doesnt it ?
Esp the idea of porting a package.