Stephen McConnell wrote:
>
>
> Peter Donald wrote:
>
>> At 10:21 AM 6/10/2002 +0200, you wrote:
>>
>>> - proposal for component management in avalon 5:
>>> 1) removal of ComponentSelector
+1 (I've done it too in my projects)
>>> 2) removal of release()
-1
Still don't understand how I can deallocate a scarse resource as soon as
possible :-/
How the hell can I release a scarse resource right away?
If processor hardware threads would never release() and use only a
timeout, what processors would we have? :-S
I agree that release is *not* compulsory for pooling, but I don't see
replacements possible for handling of scarse resources.
>>> 3) replacement of Component with Object
>>
>> +1s
+1
Why did we use _Component_ in the first place?
So that the container could recognize an Avalon Component ad treat it as
such.
What was the need?
That the Component would be sure it got treated as such.
Now, the first part is unnecessary, and the current Service part shows
it. The fact is that the second part never worked!
And guess what: users still get confused and think that Components
somehow get magically called!!!
How can we make an Object be sure that it's being treated by an Avalon
container?
>>> 4) replacement of ComponentException with exists() for lookup()
-1
Exception throwing is a contract with the caller, that states that the
caller is responsible for the Exception.
Thinking that the callee can handle its own exceptions by itself is
wishful thinking.
Saying that the caller cannot do anything about it anyway is of no use,
since someone needs to do it.
>>> 5) addition of an _optional_ lookup() method that supports hints, to
>>> enable smooth migration from ComponentSelector usage
>>
>> -1s
>
> From a pure framework perspective I'm totally in agreement with the
> above (irrespective of the pain and suffering I'm enduring with respect
> to the metainfo/metadata issues inflicted by an unmentionable
> "Australia" personality). However, if we take into account ECM and the
> interest in facilitating a smooth migration path, I see only two
> alternative; either we provide a lookup( role, hint) in the framework
> (which I dislike in terms of the curent form being dicusssed), or (b) an
> extended CM is defintion at the excalibur level that provide a bridge
> from ECM to the emerging container models.
Now, this thing of /hints/ got me thinking.
As I said previously, it seems that:
Role: what
Hint: how
This means that if I ask for an XSLT processor, I can hint to use Saxon,
but it can give me also Crimson.
No problem for me, as long as it's XSLT spec compatible (ROLE).
The problem, as Peter showed, is when I "hint" for a SSL connection.
If I get a normal connection, I *can* still connect, but I *don't* want
it. In this case, the /hint/ is mandatory and cannot be overlooked.
This makes me think that there is something missing.
ROLE: what it should do
CHARACTERIZATION: how it should do it
PREFERRED ACTOR: hint about *who* should do it
Well, this shows that hints are really not needed.
Why would I want a specific actor!?!
Inversion of Control, it's the container that gives me the actor.
Why the heck would I need a container if I ask him everything?!?
The point is that we need a sub-role.
An interface (Role), tells me what to do, but does not specify how it
should be done.
This is not something that can be forgotten, as in the SSL case.
I would deprecate hints in favor of sub-roles (or call them in a better
way, I'm no ace in names ;-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
