You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Anton Tagunov <at...@list.ru> on 2004/02/06 18:39:24 UTC
MutableConfiguration -- interface and semantics
Hi, gang!
LSU> Are there any other issues besides the ones listed
LSU> by Aaron? That is:
LSU>
LSU> a) Where does it belong?
LSU> b) Should MutableConfiguration extend
LSU> Configuration?
Yes. Three more issues.
A.
addChild( Configuration other )
addAll( Configuration other )
addAllChildren( Configuration other )
should receive deep-copy semantics (unlike DefaultConfiguration)
B.
interface MutableConfiguration
{
/**
* Create a MutableConfiguration instance
* of the appropriate class and put to the
* list of children
*/
MutableConfiguration createChild( String name );
}
C.
Do we have
getChildCount()
getChild( int no )
getChild( String name )
methods in Configuration?
If no, I will ask to add them.
And likewise in MutableConfiguration I'd like
interface MutableConfiguration
{
MutableConfiguration getMutableChild( int no );
MutableConfiguration getMutableChild( String name );
}
or
interface ConfigurationMutator
{
int getChildCount();
ConfigurationMutator getChild( int no );
ConfigurationMutator getChild( String name );
}
I just have an aneasy feeling about methods returning arrays -
feel sorry about arrays being allocated. I'm not against these
methods, just want methods for accessing children one-by-one
also.
Cheers, Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Re[2]: MutableConfiguration -- interface and semantics
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@list.ru]
>
> Hi, Leo!
>
> AT> Three more issues.
> LSU> can we move *all* your issues to a future proposal?
> LSU> I've been trying for *two weeks* to get this proposal
> through, and
> LSU> I'm not really up for extending it.
>
> Two weeks is plainly horrible.
>
> Still got a gut feeling ...
>
> with DefaultConfiguration we did
>
> DefaultConfiguration parent = new DefaultConfiguration( ... );
> DefaultConfiguration child = new DefaultConfiguration( "child" );
> parent.addChild( child );
>
> see the catch?
>
> We need a *factory method* somewhere.
The MutableConfiguration interface has a getMutableChild method that
works
just like the getChild() method, except it will create *and add* a child
node.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[2]: MutableConfiguration -- interface and semantics
Posted by Anton Tagunov <at...@list.ru>.
Hi, Leo!
AT> Three more issues.
LSU> can we move *all* your issues to a future proposal?
LSU> I've been trying for *two weeks* to get this proposal through, and
LSU> I'm not really up for extending it.
Two weeks is plainly horrible.
Still got a gut feeling ...
with DefaultConfiguration we did
DefaultConfiguration parent = new DefaultConfiguration( ... );
DefaultConfiguration child = new DefaultConfiguration( "child" );
parent.addChild( child );
see the catch?
We need a *factory method* somewhere.
Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: MutableConfiguration -- interface and semantics
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Anton Tagunov [mailto:atagunov@list.ru]
>
> Hi, gang!
>
> LSU> Are there any other issues besides the ones listed
> LSU> by Aaron? That is:
> LSU>
> LSU> a) Where does it belong?
> LSU> b) Should MutableConfiguration extend
> LSU> Configuration?
>
> Yes. Three more issues.
Anton,
can we move *all* your issues to a future proposal?
I've been trying for *two weeks* to get this proposal through, and
I'm not really up for extending it.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org