On Wed, 26 Sep 2001 07:00, Berin Loritsch wrote:
> 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.
Configuration data is configuration data regardless of whether it is flat or
hierarchial. You are prposing that the config data be partially mutable (Like
making some of Configuration objects mutable but not others in a config).
This is not something we should support IMO - hence the -1 on it ;)
> 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!
then you swap the order of merge and setParameter()?
> 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.
The functionality you propose partially readable and partially writeable data
in the same object. It is not needed functionality as it can be implemented
as I have indicated without any changes to current framework setup.
> 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.
Changing Framework to reflect different configuration schemes for every
different project Avalon is used in is ludicrous.
I have a configuration scheme like Axis. Options however have other features.
They can be "archive" options (will be written out when saving options), they
can be "noset" (not able to be set by normal code), they can be "latch" (only
able to be set within a specific phase), "serverinfo" (replicated to
clients), "clientinfo" (replicated to server), etc
How many would I get to add to Avalons Parameters object? All of them, some
of them, none of them?
> Adding the ability to identify the attribute names is FS (flexibility
> syndrome).
as is adding ability to modify element names. It is a product specific demand
to why not place it in the product and not in the framework that is meant to
be generalized.
--
Cheers,
Pete
--------------------------------
My opinions may have changed,
but not the fact that I am right
--------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
