> >It is a tradition, a recommendation, and a "best practice". It is _not_
> >a requirment.
>
> I have to question this "best practice".
it is because your components will be useable in the broadest possible
scope: ECM, phoenix, SM, merlin, ... very importantly: cocoon.
And it doesn't really "hurt". Or does it? (...)
> >We could tighten this to the lookup name should start with the results
> >of getClass().toString() called on the role interface, minus the
> >starting "interface ".
>
> This would introduce an artifical and unnecessary limitation?
yes. Notice the "could" instead of "should". Practical usage of avalon
framework wouldn't really be a lot more difficult either way - just some
potential extra typing work.
> >You forget the other alternative allowed (regardless of whether this is
> >by code or contract) is for framework users to be their own authority.
>
> The scalable approach is for the component to manage its own role
> namespace (through a clean seperation of lookup role and the
> computational dependecy).
you put it so much clearer =)
> >- Leo, who always follows "best practice" in his own projects
>
> Steve - who tends question and understand why something is a best
> practice before following.
>
> :-)
we at avalon tend to do that into the extreme...sometimes following the
herd (yes there's a distant pun ;) works just as well...
:D
- Leo, sometimes uses quotes ("") to denotate more than just strings
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
