Context.put?

[Michael McKibben <mi...@hihat.net>]

I've been finding myself wishing for a Context.put(key,value) on the
Context interface. Why does Context only have a get? It seems that you can
still support an unmodifiable Context by just throwing an exception (ala
an unmodifiable java.util.Map). I know supporting this change for the
immediate future would be bad since this will break any Context impls out
there (although, in practice don't most people just use DefaultContext?)
but how about for 5.0? It just bugs me having to pass the Context impl to
methods that need to populate the context. I would rather just have to
change code in one spot if I need to swap out a Context impl.

So, what do you guys think? It's just *one* more method :)

Regards, 

--mike 


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Context.put?

[Peter Donald <pe...@apache.org>]

On Wed, 20 Feb 2002 10:10, Michael McKibben wrote:
> I've been finding myself wishing for a Context.put(key,value) on the
> Context interface. Why does Context only have a get? 

because that was the minimum interface that the concept of Context supported. 
If you look at how it is used - most projects will define a sub-interface of 
it. For instance phoenix has a BlockContext (which is largely read-only) 
while myrmidon defines a TaskContext (which is writeable and readable). 

So for the moment I would suggest you do something like

public void contextualize( Context context )
{
 _context = (MyContext)context;
}

and add any auxilliary methods to the MyContext interface.

> It seems that you can
> still support an unmodifiable Context by just throwing an exception (ala
> an unmodifiable java.util.Map). I know supporting this change for the
> immediate future would be bad since this will break any Context impls out
> there (although, in practice don't most people just use DefaultContext?)
> but how about for 5.0? It just bugs me having to pass the Context impl to
> methods that need to populate the context. I would rather just have to
> change code in one spot if I need to swap out a Context impl.
>
> So, what do you guys think? It's just *one* more method :)

Unfortunatley it is not really an option for avalon4.x due to backwards 
compatability but I think it would be a good idea to reexamine it for the 
next iteration.

-- 
Cheers,

Pete

-----------------------------------------------------------
 Don't take life too seriously -- 
                          you'll never get out of it alive.
-----------------------------------------------------------

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Context.put?

[Stephen McConnell <mc...@apache.org>]

> -----Original Message-----
> From: Michael McKibben [mailto:mike@hihat.net]
> Sent: Wednesday, 20 February, 2002 00:10
> To: avalon-dev@jakarta.apache.org
> Subject: Context.put?
>
>
> I've been finding myself wishing for a Context.put(key,value) on the
> Context interface. Why does Context only have a get? It seems that you can
> still support an unmodifiable Context by just throwing an exception (ala
> an unmodifiable java.util.Map). I know supporting this change for the
> immediate future would be bad since this will break any Context impls out
> there (although, in practice don't most people just use DefaultContext?)

Hi Michael:

I pass around either a Context instance or a interface derived from Context.
Typically I construct and populate the context within some implementation
class and use the Context (or derived interface) when exposing it to
anything
else.  Concerning DefaultContext - sometime - yes - but I have several
instances
here of objects with an inheritance slot that is already taken up and its
easy to implement the Context interface on an existing class.

Cheers, Steve.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>