beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lawrence Jones" <ljo...@bea.com>
Subject RE: Control concept names
Date Fri, 13 Aug 2004 23:53:30 GMT
If we restrict this further and say of B and C at most one of them can
implement either @ControlInterface _or_ @ControlExtension then I agree. 

If we don't do this then any given @ControlExtension must have at least
one @ControlInterface somewhere in its tree. So say B is the
@ControlInterface in your example below, if C is a @ControlExtension
then it must inherit from something which is a @ControlInterface at some
stage and hence you end up with 2 public interfaces and 2
implementations. On the other hand if C is just a plain old java
interface there's no such issue.

Basically this is saying that for controls we would not provide
"multiple inheritance" of @ControlInterface's / @ControlExtension's even
though they are both interfaces.

Sound good?

Cheers,

Lawrence

-----Original Message-----
From: Ken Tam 
Sent: Wednesday, August 11, 2004 4:30 AM
To: Beehive Developers
Subject: RE: Control concept names

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?
> > 
> > 
> >   
> >   
> > 
> > 
> > 
> > 
> 


Mime
View raw message