|There's more than one way to do things|
Re: Yet Another Perl Object Model (Inside Out Objects)by adrianh (Chancellor)
|on Dec 15, 2002 at 04:06 UTC||Need Help??|
++ (when I get tomorrows votes anyway)
Interesting approach. I've got a class that does something similar using a different approach --- so I'll probably annoy everybody with YAPOM class later on today :-)
The thing that I would disagree with is autogenerating a set/get method for every attribute. It's rare that I have objects where this is true. Even when it is true, there is some checking/transformation of arguments that takes place - making auto-generation like this impractical. I want access to those hashes!
A quick comment on:
A common problem that is attempted to be solved is that of internal attribute clashes in inherited modules. I personally find this a little strange as I tend to not find this to be a noteworthy issue in my day to day use of objects in perl.
Basically, I agree, but it's not the only advantage that the technique gives you - you also get compile time checking of attribute access, which is a good thing, along with the ability to inherit from non-hash based classes.
There is also the fact that, while these sorts of bugs are not common, they can be complete sods to discover.
I can't remember the precise details, but we had a bug that was showing up on some servers and not on others. It turned out that we had updated module A, which sometimes caused an update of module B (depending on the version currently installed), which was a subclass of module C, which was used by our class D.
The latest version of B added an entry to the hash that was also used by D, breaking it in certain conditions.
Took us two days to figure out what was going on.
However - this sort of thing is rare :-)