Hi, Niclas!

A couple of random thougts:

1. ======================

LSU == Leo Sutic
NH == Niclas Hedhman

LSU> "I have code that currently pass around a DefaultConfiguration
LSU> instance."

NH> I think it would help a lot by specifying WHERE such "pass around"
NH> is being made. When I see this, I assume "to the component",
NH> which is a big -1.

I recall a similar thing with DefaultServiceManager in Fortress.

DefaultServiceManager is read-write,
ServiceManager is read-only.

While "cooking" ServiceManager for a new Component
parts of Fortress passed half-ready instance around a lot.

It would be easier to

A)
    void update( DefaultServiceManager dsm )
    {
        dsm.put( "foo", bar );
    }

but we did

B)
    ServiceManager update( ServiceManager parent )
    {
        ServiceManager sm = new DefaultServiceManager( parent );
        sm.put( "foo", bar );
        return sm;
    }

Same thing with all lifecycle-related entities:
   Context, ServiceManager, Configuration.

So, A or B?

A is more efficient

    not only at component construction time,
    but at runtime also, at each lookup it's better to have
    ServiceManager hierarchy one level deep then 10 levels deep

    and we have users _extremely_ concerned with this

B is more generic

    there are different implementations of java.util.List:
    LinkedList, ArrayList

    likewise there may be different implementations of
    Configuration, ServiceManager, Context:

    for desktop/server environment

        new HashMap( 128 );


    for Java2ME environment

        String[] m_names = new String[5];
        String[] m_values = new String[5];

    these might be generated by some factory method
    or some Factory class.

Is this a use case?

2. ======================

NH> public interface ConfigurationMutator
NH> {
NH>    void setXXX( XXX value );
NH> 
NH>    Configuration getCurrentConfiguration();
NH> }

In fact the idea was a tad different:

public interface ConfigurationMutator
{
    void setXXX( XXX value );
 
    Configuration getConfiguration();
}

I ment both

    setXXX()

and

    getConfiguration().getXXX()

would operate the same HashMap, like

DefaultConfMutator implements ConfMutator
{
    Map m_map = new HashMap();

    void set( key, value )
    {
        m_map.put( key, value );
    }

    class MyConf implements Conf
    {
        get( key )
        {
            return m_map.get( key );
        }
    }

    Conf m_conf = new MyConf();

    Conf getConf()
    {
        return m_conf;
    }
}

This is to minimize object creation (re: Java2ME again).

And if we really need a static replica we could

    Conf liveConf = mutator.getConf();
    Conf staticReplica = ConfUtil.replicate( liveConf );

Cheers, Anton
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to