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? Hubert > riyaz > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
