Don't ask to ask, just ask | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | 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 :-) In reply to Re: Yet Another Perl Object Model (Inside Out Objects)
by adrianh
|
|