avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Proposed change to Parameters:
Date Tue, 25 Sep 2001 21:00:07 GMT
Peter Donald wrote:
> 
> 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?

yes, but again, see below.

> > 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.

I'm not talking about config trees.  I am talking about Parameters.  Inherently
flat data.  Getting back to setting up the Parameter object, it is terribly
inconvenient to do the hierarchical approach.  Plus, you have an undefined
action when you merge Parameters.

For instance:

Parameters testcase = new Parameters();
Parameters mergecase = new Parameters();
mergecase.setParameter("merge", "case");
mergecase.makeReadOnly();

testcase.merge(mergecase);
testcase.setParameter("merge", "value");

"value".equals(testcase.getParameter("merge")) == true // This is what we don't want!

The implementation that I propose is able to lock all parameters
in a read-only Parameters object--even when merged with a non-read-
only parameters object.

> > > > 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.

Requiring other projects to either change their configuration schemes or
reimplement ( extend or whatever ) parameters objects simply so they can
change what they call a parameter is kind of rediculous.

Adding the ability to identify the attribute names is FS (flexibility syndrome).

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message