On Wed, 26 Sep 2001 05:31, Berin Loritsch wrote:
> > I am fairly sure I don't like this. If parts are read-only and parts are
> > read-write then IMHO they should not be part of same Parameters object. A
> > possible solution to get around this would be to allow Parameters to have
> > a parent and make it possible to specify who to read properties from
> > first. (This would mean that properties were always accessed from parent
> > first and then from child or vice versa). So you would have something
> > like
> >
> > Parameters parent = new Parameters();
> > ...setup immutable variables here...
> > parent.makeReadOnly();
> >
> > Parameters child1 = new Parameters( parent, false );
> > ...setup non "locked" parameters here...
> >
> > Then later on
> >
> > Parameters child2 = new Parameters( parent, false );
> > child2.merge( child 1 );
> > ...setup non "locked" parameters here for second time...
> >
> > Actually this is what I partially do in quite a few of my apps. But I do
> > it manually and instead of using term parent I use term defaults ;)
>
> There are three issues with your approach:
>
> 1) If the parent is accessed first, then you can never change the value of
> a parameter. Parameters will always return the value of the parent.
You mean the parents values are immutable/locked. Isn't that what you wanted?
> 2) If the child is accessed first, then you can override a "locked" value.
right. Which is why you would specify that parent is accessed first when you
wanted it to be accessed first?
> 3) When deriving your Parameters object from a Configuration object set,
> you cannot determine which are meant to be locked, and which are allowed to
> be changed. Instead you are forced to have the parameters specified in two
> locations. This makes automatic incorporation in Excalibur's
> ComponentManager near impossible.
Right. But fundamentally I don't think we should be supporting partial
mutability in any sort of configuration data. We don't have partially mutable
Config trees and I don't think we should support it.
> > > and a "fromConfiguration"
> > > method that allows you to specify the element name for a parameter.
> > > The attributes would be the same, but a project would be able to
> > > use the name "option" instead of "parameter" if it wanted to.
> >
> > Seems kinda ugly to me.
>
> If you have a better way of implementing the same thing let me know. The
> thing is that we are forcing all configuration schemes to be the same. The
> new fromConfiguration() method allows projects to easily support different
> names without breaking anything.
>
> The default behavior has not changed in the least.
I don't think you see my point. Avalon/Framework is not meant to provide all
implementations of these sorts of things. What you proposed adding seems very
application specific and limited in usefulness. Why can't Axis use their own
method of constructing Parameters? That seems much more sensible to me.
If it is absolutely essential that these features are present using the
mechanisms you specified couldn't you just do something like
class AxisParameters extends Parameters
{
fromConfiguration();
setProperty( key, value, isLocked );
}
--
Cheers,
Pete
-------------------------------------------------------------
| Egoism is the drug that soothes the pain of stupidity. |
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
