Nicola Ken Barozzi wrote:
>
>>>>>> 3) replacement of Component with Object
>>>>>
>>>>>
>>>>> +1s
>>>>
>>>>
>>> +1
>>>
>>> Why did we use _Component_ in the first place?
>>
>>
>>
>> beautification.
>>
>>
>>> 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. 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.
>
>>>>>> 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.
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]>
