Class named Object
Moderator: General Moderators
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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
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: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.
- 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
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
(#10850)
- feyd
- Neighborhood Spidermoddy
- Posts: 31559
- Joined: Mon Mar 29, 2004 3:24 pm
- Location: Bothell, Washington, USA
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: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
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:Reflection is difficult/complicated
I haven't had any problems. Care to elaborate?ole wrote:Problems with generating documentation
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: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.
Not for this system.ole wrote:More code to maintain, temptation to tweak having far reaching implications.
I'll agree, there is a performance hit, but that's what programmers get when they choose to sidestep accessors and mutators.ole wrote:Performance hit
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.ole wrote:One, indeed most, can write perfectly good code without it