Stephen McConnell wrote:
>
>
>>> Nicola Ken Barozzi wrote:
>>>> How can we make an Object be sure that it's being treated by an
>>>> Avalon container?
>>>
>>> we cannot (in a way expressed in java code). Is there a need?
>>
>> Definately, IMNSHO.
>> I've seen many users start Avalon Components with new, and wait to see
>> the Avalon interface methods called :-O
>>
>> If the component isn't created in a container, it woud be cool if it
>> could barf.
>>
>> <attention mode="heretic">
>> Component interface as a teg interface is useless and in some cases
>> bad for reasons already expressed.
>> But maybe we could make an abstrace SafeService that can act as a base
>> class to extend to make a Service that can be created only by a
>> container: private method, creator method and check of proper order of
>> interface calling.
>> </attention>
>
> *eeek* - drop the capatilized Container and I'm with you.
container (it's what I meant ;-)
> A component is
> described in terms of interfaces and lifecycle semantics that are
> managed by an implementation. We tend to refer to the imnplementation
> as a container because this makes sence in the overall pattern of usage.
> What you really need to rugged testing in the contents you make public
> to make sure that usage outside of a managed context results in quick
> failure. This is also one of the prime objectives of Merlin - a
> mechanisms to do exacly what your user's want to do - just run the
> component.
I want the object to complain if its lifecycle methods are called in the
wrong order or not called before other things.
Basically checking that it's being created by an external controller
entity that is not simply new().
>>>>>>> 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
>>>
>>> ...
>>>
>>>
>>>> ROLE: what it should do
>>>> CHARACTERIZATION: how it should do it
>>>> PREFERRED ACTOR: hint about *who* should do it
>>>
>>> nope.
>>>
>>> The role determines what part a component plays in your application; it
>>> is perfectly valid for the role to include information on the "how".
>>>
>>> Tight coupling of role to interface name is merely a convenience (it
>>> allows us to get away with easy casts).
>>
>> I'm not so sure.
>> What do the Connection and SSLConnection components do?
>> Make a connection.
>> They use the same interfaces.
>>
>> I should be able to say that I just need to make a connection or that
>> I need to make a *certain* type of connection.
>>
>> If we say that SSLConnection is a role itself, it will not be given me.
>>
>> The fact is that sometimes I want the container to decide for me,
>> sometimes I don't.
>> When the container decides, I just specify a role.
>> When I decide, I also specify a sub-role.
>>
>>>> Well, this shows that hints are really not needed.
>>>
>>> yup. Except we have to take into account an already existing CS.
>>
>> That use a hint as a sub-role usually.
>>
>>>> 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 ;-)
>>>
>>> strings are pretty free-form. It is easy to describe both a role "king
>>> of all England" and a sub-role "mad" in a single string: "mad king of
>>> all England".
>>
>> This is an implementation detail.
>> Or you do Role,SubRole or "role/subrole".
>> It's not a problem, but semantically there is a point in defining role
>> and subrole.
>>
>
> Role is simply a key that is unique within the scope of the CM/SM that
> is supplied to a component. Any semantics beyond that imply that your
> component has a private arrangement with its container in that the
> semantics of the lookup interface are modified by the introduction of
> dark-magic ... which means its not a portable component.
Hmmm, I mean that simply using a unique key is not enough.
In sentences, I want subjects (the container), verbs (the ROLE) and
other stuff that specializes (sub-role).
I need hierarchy, with the ability of stopping at a more generic level
(do it!) or going in more detail (do it with SSL!).
--
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]>
