On Wed, 2003-02-12 at 00:23, Stas Bekman wrote: > Nathan Byrd wrote: > [...] > > fields Pragma > > ------------- > > Advantages: > > * More straightforward approach > > * Less code to add to module > > > > Disadvantages: > > * Based on pseudo-hashes - may have problems with reloading, etc > > * Unknown whether it changes performance (due to "typed lexical" > > limitation of pragma) > > * Forces developers to 'use base' and/or 'use fields' in sub-class, can > > cause non-obvious error otherwise > > > > Array based > > ----------- > > Advantages: > > * Easy to change code to change base class implementation in the future > > * Good encapsulation (ability to override methods in future without > > breaking sub-classes) > > > > Disadvantages: > > * Adds a custom non-standard extending technique > > * Need to explain method in doco for adding sub-class data (via > > "public"), vs. pointing the developer to an existing perl document. > > * Doesn't work with multiple inheritance (probably not a big deal for > > most RegistryCooker sub-class developers though) > > Thanks for the summary Nathan, > > Looking at it, I favor your original proposal, as then we have a complete > control and any bugs are our own fault. > > Considering that we go with that approach. Are there any in-core modules that > can be used for creating/managing accessors? I know there is a whole lot of > them on CPAN, but we don't want to create extra dependencies. >
I haven't found any in-core that I know of - but I'll take another look. > Another approach to simplify your original suggestion, is to move on to hash > based objects. I doubt it'll be of any significant difference, since most work > happens in the scripts themselves. I guess a benchmark will show better. But > if we go with it, subclasses can simply bypass the accessors (we could just > skip them) and work directly with the hash. Dunno, what's the best way to go. > I kinda like this idea. I think we may *still* want to have accessors/mutators, for the reasons above (encapsulation, etc), but with a hash based implementation we may be able to just write accessors/mutators manually for the base instead of using the custom extension stuff (and sub-classes could do the same). It seems to me that if a mechanism for encapsulation is provided, and the developer bypasses it, then they get what they deserve in terms of their module breaking with future releases (especially if the hash elements are named with a leading underscore.) The performance could be an issue - let me think about this a little and do some playing around with the code tonight. -- Nathan Byrd <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
