Hi Kyle,
Thanks very much for your detailed explanation (a little too profound for my
article though :-). I'll express my response on this issue as a reply to
Mike Foster's message.
Regards,
Ias
> Hi Ias,
>
> In an earlier version of Controls (that were part of
> Workshop), we tried to do something very much like this. It
> definitely makes it easy to have a single source artifact in
> the case like you show below, where the control only exposes
> methods, but not properties or events.
> But this actually begins to break down some for a couple of
> reasons when you move to more complex cases:
>
> - if the control needs to have properties (PropertySets) or
> events (EventSets), then these really can't be defined inside
> the impl, because ultimately clients need to see them... you
> could replicate them out to a generated public interface (as
> you have for the methods), but then you actually have two
> different copies of the same interface w/ no relationship,
> and it makes it hard to align the client view of the
> control's properties and events (which would be implemented
> in terms of the public interface versions) and the impl's
> view of them (which would be based upon interfaces declared
> internally).
>
> - another issue is that in your example below won't actually build
> under APT. The reason is that APT tries to parse a source file and
> will only generate derived sources if the parse of the original source
> succeeds. But in the case below, you have 'HelloImpl implements
> Hello' where 'Hello' is in fact a generated artifact from HelloImpl.
> So when APT processes this source file, it is going to
> complain that there is no type 'Hello' and never get to the
> point where it actually
> is able to generate 'Hello'. Unfortunate but true... the basic rule
> is that APT doesn't allow you to have a source file that has
> a dependency upon a source file that is generated from the
> original source file.
>
> - there is also the more theoretical problem that if the
> interface is derived from the impl, you might inadvertently
> break your clients when modifying the implementation (because
> the derived interface signature changes)... this is a bit
> subtle, but a trap that is easy to fall into once you've made
> it so convenient to do the auto-derivation.
>
> - one thing that is possible is actually to go in the other direction:
> to derive a stubbed out implementation from only the public
> interface declaration (since nothing in the public interface
> ever ref's the impl
> class, thus avoiding the apt dependency issue). This is nice for an
> initial stub of the control impl, but starts to break down in
> iterative dev scenarios (how can i regenerate my stubbed impl
> after i've actually modified some of the stub methods).
>
> If you think I'm missing or misunderstanding something, please let me
> know! Keep those ideas coming!
>
> -- Kyle
>
> On Sun, 21 Nov 2004 18:23:29 -0000, Ias <[EMAIL PROTECTED]> wrote:
> > Hi all,
> >
> > While I was writing a control part in my article, I felt
> that "why not
> > just coding an implementation?". For example, in control tutorial
> >
> > package hellocontrol;
> >
> > import org.apache.beehive.controls.api.bean.*;
> >
> > @ControlImplementation(pairedInterface="hellocontrol.Hello")
> > public class HelloImpl implements Hello {
> > public String hello()
> > {
> > return "Hello, World!";
> > }
> > }
> >
> > leads to generate
> >
> > package hellocontrol;
> >
> > import org.apache.beehive.controls.api.bean.ControlInterface;
> >
> > @ControlInterface
> > public interface Hello
> > {
> > public String hello();
> > }
> >
> > It seems obvious that in many (simple) cases an interface for a
> > control is a duplicate from an implementation in terms of
> method declaration.
> >
> > What do you think of this?
> >
> > Ias
> >
>
