avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: [Proposal] WriteProtectable/ReadOnly interfaces
Date Wed, 11 Jun 2003 01:31:17 GMT

Hi,
Sorry if I don't fully appreciate your example, but;

Could you provide some reasoning around what you are trying to achieve?

Let me attempt;
You want to have a way to force that an object can no longer be modified, 
after some point in time. The ReadOnly interface is intended as a marker that 
an object can not be modified, and the WriteProtectable is an interface to 
"turn on" the ReadOnly functionality.

Provided this is the case, why do you need to "pollute" the Avalon Framework
interfaces with such a construct?
How do you see that the containers need to be involved in this scheme at all? 
Is there a "time"/"sequence" constraint on when a WriteProtectable turns into 
a ReadOnly?
You mention that it would be used on ServiceManagers, but if the 
ServiceManager user does not need to know, then it is an implementation 
detail and irrelevant to Framework.

Maybe I missed something important...

Niclas

On Tuesday 10 June 2003 12:15 am, Anton Tagunov wrote:
> Hi, All!
>
> I think that we have got one more interface
> crystalized in our works:
>
>     public interface WriteProtectable
>     {
>         void makeReadOnly();
>     }
>
> As I will show later it also needs a twin
> marker interface ReadOnly:
>
>     public interface ReadOnly
>     {
>     }
>
> For instance DefaultServiceManager is WriteProtectable
> while FortressServiceManager is ReadOnly.
>
> -------------
>
> This interfaces are proposed to have a XXXUtil.makeReadOnly()
> method to operate them: (a sketch)
>
>     public void makeReadOnly( Object obj )
>     {
>         if ( obj instanceof WriteProtectable )
>         {
>             ((WriteProtectable)obj).makeReadOnly();
>         }
>         else if ( obj instanceof ReadOnly )
>         {
>             //do nothing
>         }
>         else
>         {
>             throw new IllegalArgumentException( "..." );
>         }
>     }
>
> --------------
>
> This methods may be usefull when we extend any kind of
> class via subcalssing, f.e. a container or a component.
>
> Here's a usage example:
>
>     class Abstract
>     {
>         protected void initializeGreat()
>         {
>             m_great = createGreat();
>             XXXUtil.makeReadOnly( m_great );
>         }
>
>         protected Great createGreat()
>         {
>             DefaultGreat great = new DefaultGreat();
>             great.put( foo );
>             great.put( bar );
>             return great;
>         }
>     }
>
>     class Derived extends Abstract
>     {
>         protected Great createGreat()
>         {
>             Great parent = super.createGreat();
>             final DefaultGreat great;
>             if ( parent instanceof DefaultGreat )
>             {
>                 great = (DefaultGreat) parent;
>             }
>             else
>             {
>                 great = new DefaultGreat( parent );
>             }
>             great.put( blah );
>             return great;
>         }
>     }
>
>
> --------
>
> Great could be Context, ServiceManager, etc.
>
> --------
>
> This mail is on introduction of WriteProtectable/ReadOnly.
> Do you think it's a good idea to put them somewhere to the
> framework, say o.a.a.f.writeprotection (bad name :-((  )
> and make all the classes that have a makeReadOnly() method
> implement WriteProtectable?
>
> --------
>
> Where can XXXUtil.makeReadOnly() go?
> (My other mail is on a similar subject,
> XXXUtil.get( context,key,defaultValue ), where can that go?
> Should they both go to one class? Where can it live?)
>
> WBR, Anton
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org


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


Mime
View raw message