On 5/26/05, Hubert Rabago <[EMAIL PROTECTED]> wrote: > On 5/26/05, Riyaz Mansoor <[EMAIL PROTECTED]> wrote: > > Hubert Rabago wrote: > > > > my intention here was to have _all_ the accessor methods of "properties" > > in BaseConfig - i guess it can be a hinderance when the classes a > > changing rapidly as u've mentioned. i think of it as a 'cleaner' way :) > > > > That's what we have now, accessors of "properties" in BaseConfig. In > fact, that's the only way to access them, which goes against the > convention set by most (if not all) other config objects. Other > config objects declare their fields as protected, allowing custom > subclasses to access those fields directly. I'll probably change > "properties" in BaseConfig to follow this convention. > > > > > eg: pass the childConfig to the ParentConfig instead of the passing the > > parentConfig (baseConfig) to the childConfig. > > It took me a while to understand what you were saying here, but I > think I finally get it. I'm not opposed to the idea, but stepping > back, I'm not entirely convinced that one is cleaner than the other. > We've been discussing this only from the perspective of copying > arbitrary properties of config objects held by an ActionConfig. The > rest of the config objects have been doing > "child-inherits-from-parent" as well. If "parent-sets-child-values" > is truly that much better, I'd want to use that for the rest of the > config objects. Not just when copying full config, but also when > extending overridden configs. > > > > > again, extending classes would have limited access to the properties object. > > This point is independent of "parent-sets-child-values" vs. > "child-inherits-from-parent". Whichever wins out there, doesn't > convince me that superclasses should forbid subclasses from accessing > fields. > > > > > it comes down to the first point u made. :) ie: > > > > > I'm not sure I want to forbid config subclasses from accessing > > > their properties directly. I've come across several libraries > > > and frameworks which used "private" all throughout and made it > > > difficult if not impossible for me to customize certain behavior. > > > > different ways of thinking ;) > > > > Yes, but it doesn't mean I'm not open to other ideas. In this case, > I started out reading from everywhere that fields should be private, > and everything should go through accessors (even subclasses). But I've > been burned by that restriction LOTs of times (in some cases, I had > to rebuild entire libraries to get access to the fields I needed), so > I'll need some convincing. If private fields are what's best, how come > every other config field is protected?
I'm not sure how you can be burned by not having direct access to a member while there are getters and setters available. On the other hand, making a member directly accessable severely curbs the ability to change the class implementation without breaking backwards compatibility. Suppose at some point that you decide you don't want to keep a reference to the member in the class, but retrieve it on the fly. Or perhaps you decide that you want to keep the reference in a cache of weak references. You're hosed, because any code that used that member is now broken. This is something that I really dislike in a lot of the Struts code. For much of it, it's no doubt too late to change. However, I'd very much prefer that we don't continue to exacerbate the problem. -- Martin Cooper > Hubert > > > riyaz > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
