hI haven't fully considered the ramifications of these cases, but I
think it makes sense to define some restrictions.
1) All @ControlInterface ancestors of an @ControlExtension must be
rooted in a single subtree. For example:
A extends B, C
B extends D
C extends E
if A is an @ControlExtension, at most one of (B,C) can be an
@ControlInterface. I think this restriction is necessary because
otherwise I'm not sure how you'd resolve implementations. More thoughts
later..
> -----Original Message-----
> From: Lawrence Jones
> Sent: Tuesday, August 10, 2004 9:39 PM
> To: Beehive Developers
> Subject: RE: Control concept names
>
> The naming convention ("Control Type" and "Control Public
> Interface") sounds good.
>
> One small thing though. In theory there's nothing to stop you
> from implementing multiple interfaces at each stage i.e.
>
> @ControlExtension
> public interface Foo extends Abc, Def
>
> Foo, Abc and Def are all interfaces and all have
> @ControlExtension defined.
>
> And similarly:
>
> @ControlInterface
> public interface Bar extends Tuv, Xyz
>
> where Bar, Tuv and Xyz all have @ControlInterface defined.
>
> This is _not_ a typical usage but still the possibility remains.
>
> Typically you want to get the "nearest" @ControlInterface
> from a given @ControlExtension. To do this you'd want to
> follow Class.getInterfaces() on Foo up the tree until you hit
> a Class that defines @ControlInterface. But there could
> theoretically be multiple of these so when we define the way
> of getting to a control public interface from the control
> extension we should probably define some API such as:
>
> public Class[] getControlPublicInterfaces();
>
> which will return this list.
>
> In the vast majority of cases I imagine there'd only be 1
> element in the array, but just in case.
>
> Cheers,
>
> Lawrence
>
> > -----Original Message-----
> > From: Ken Tam
> > Sent: Monday, August 09, 2004 6:24 PM
> > To: Beehive Developers
> > Subject: Control concept names
> >
> >
> > Consider a general inheritance chain of interfaces for controls,
> > annotated thusly (base interfaces on the bottom):
> >
> > @ControlExtension public interface Foo <--- this is an interesting
> > interface
> > @ControlExtension
> > .. etc
> > @ControlExtension
> > @ControlInterface public interface Bar <--- this is an interesting
> > interface
> > @ControlInterface
> > .. etc
> > @ControlInterface
> >
> > There is a BarImpl.jcs present.
> >
> > This results in the generation of:
> >
> > class FooBean
> > class BarBean
> >
> > (as well as Bean classes for the intermediary @ControlExtension and
> > @ControlInterface interfaces in the chain that I've left nameless).
> >
> > What do we call these artifacts? Here's a proposal:
> >
> > When discussing Foo:
> > Foo - "the control type"
> > Bar - "the control public interface"
> > FooBean - "the control bean"
> > BarBean - not interesting
> > BarImpl.jcs - the control implementation
> >
> > When discussing Bar:
> > Foo - not interesting
> > Bar - "the control type" _and_ "the control public interface"
> > FooBean - not interesting
> > BarBean - "the control bean"
> > BarImpl.jcs - the control implementation
> >
> > I'm open to replacing "control type" with "control interface" or
> > "control interface type". I think "control interface" is somewhat
> > confusing when paired with the above usage of "control public
> > interface", but perhaps "control type" is just a little too odd?
> >
> >
> >
> >
> >
> >
> >
> >
>
