Re: reduction ad unum

[Stephen McConnell]

Nicola Ken Barozzi wrote:

Stephen McConnell wrote:

Leo Sutic wrote:

Fourth, you do not provide any reason at all for a context. Reading your

mail, my conclusion would be to dump the Context completely. I think it

has been shown that everything can be realized as a service, and then

we would not be limited to constant-value lookup (which is more suitable

for a Configuration anyway).

Your making the assumption that a container can only provide canstant -values in context. I don't agree with assumption. Take for example a container that is providing an activation timestamp, the key-chain of the invoking user, and a classloader. These values will typically be different in every application of contexualize. These values canot be expressed in a configuration, or parameters, or under the Serviceable or Composable interfaces.

Then please comment on the below code.

What's the real difference? How can a coder easily decide what to use?

Timestamp timestamp = (Timestamp) context.get("tstamp");

Let's take this back just a tiny little step and presume that you asked be any of the following:

Date date= (Date) context.get("date");
Timestamp timestamp = (Tiestamp) context.get("tstamp");
CertPath path = (CertPath) context.get("certificate-path");
ClassLoader classloader = (ClassLoader) context.get("classloader");

I'm not really concerned to much about the complexity of these respective objects, but I (looking from the point of view of a component) know that these things provide me with me runtime execution "context". The timestamp, path and classloader collectively give me my working context.

But to answer you question, well, read on ...

  VS

TimestampService tss = (TimestampService) servicemanager.lookup("tss");

Timestamp timestamp = tss.getTimestamp("tstamp");

The difference here is that I (the component) have been supplied with a service, not a timestamp. There are implications here. Do you (assembler) really want to provide me with the service or do you want to supply me with an immutable timestamp data structure. If I am a component that simply take the timestamp data structure, and my task is to do things with that timestamp object, maybe to log the information and create a time stamped certificate, I don't need a TimestampService. If you (container) are any good, why can't you give me want I want in the form that I want it? I want a timestamp data instance - give me a timestamp instance - don't give me a service because that means that I (the component implementation) all of sudden has to have more stuff in me that knows about the operations on a particular timestamp service and that binds me to you idea of how a timestamp service works. This reduces my potential for reuse. I (the component) don't care about timestamp services - I don't want to care, I just need the f** time stamp, and if the timestamp is a java.util.Data I'll be really happy.

  VS

Context cs = (Context) servicemanager.lookup("context");

Timestamp timestamp = (Timestamp) cs.get("tstamp");

In this scenario you taking away the explicit notion of the separation of the supply of data from the supply of services. With the existence of Contextualizable (combined with meta) I (the component implementation) can declare that I need a timestamp instance to do my job. By pushing this into a service, I've lost the ability to declare to a container my requirements pertaining to data. If you come back and tell me that I can still declare my context criteria but the only difference is how I get supplied with the data, then I'll say that (a) your proposing the removal of an import separation of concerns between data and service, (b) one line of code is better then two, and (c) that's the way it is already, and (d) don't stuff with it, and finally (e) all that is needed is some good documentation that presents these seperations clearly, presents guidelines, explains that sometime you can look at something as a service, and then think about it and look at it again as a context enty value. The important thing to understand is that manager.lookup() verus context.get() have architectural implications - the sort of things you get through lookup as the course grained service provided by other components, whereas the sort of thing one typically supplies via context are finer-grained objects (Date, File, Map, MyHelper, etc.).

Treat me like I'm totally stupid - just give me what I need, - I need a timestamp, and I need CertPath. Don't give me anything more than what I need.

KISS.

Cheers, Steve.



--

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net




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