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
>
