> > I guess my take is that this should be a tooling issue. I > would favor a IDE integration that keeps both files in sync > with some restrictions mentioned above. Or a common design > surface. Ias, I'm interested to know what you think of all > these options :) >
At this point, it may interest you (keeping your eyes on this message thread) all to look into how EJB 3.0 cope with a similar issue to ours. 3.1 Requirements for Stateless Session Beans 3.1.1 Business Interface A session bean must have a business interface. This interface may be implemented by the session bean, or it may be generated. The above excerpt from EJB 3.0 ED shows two approaches for interfaces. Furthermore, 9.2 Annotations to Specify Local or Remote Accessibility The Remote annotation can be applied to a business interface of a session bean or to a session bean class. When applied to a business interface, it denotes that the interface is implemented by the container as a java.rmi.Remote interface. When applied to the bean class, it denotes that the generated business interface of the bean class is a remote business interface. Therefore, a (session) bean class can cause its corresponding BI to be generated by @Remote annotation. Notwithstanding these statements, JBoss EJB 3 is not supporting the feature for some reason (please refer to http://www.jboss.org/index.html?module=bb&op=viewtopic&t=55153 for more discussion on the issue). I fully understand that there are tricky problems with apt (and metadata processing) to handle "concrete to abstract" cases. (Maybe that's why EJB 3 folks haven't settled "generated intefaces" issue yet.) In order to avoid the strictness of standard metadata processing model, a seed (yes, the specially annotated file :-) can be used to produce both interface and implementation for a component. The main cons of this seed approach is that a programmer doesn't have to be busy jumping (or switching) between the interface and the implementation. What component developers need to keep in their mind is that the seed will control everything, so if they want to change anything about a component, "don't modify the generated artifacts, but do update-and-compile the seed". However, all these confusions and debates are based on "Non-IDE VS IDE". If we can assume that a developer must use an IDE, we don't need to think about this kind of matter at the level of framework. Minimize framework for deployment+runtime and maximize IDE for development can be a compelling methodology. seed ------------> inteface and implementation ---------> service compile deploy --------------------------------- ------------------------------------------ (development time) IDE (runtime) framework Again, one can argue "giving more jobs to IDEs and making frameworks and containers lighter". I don't have any personal favor on that, in other words, the concept of "seed" can exist in Beehive framework or IDEs for Beehive. One thing I hope is to make Beehive full with honey from flowers,which in turn thrive with spread seeds. Ias P.S. Ias' postulate: A developer uses an IDE :-) > -Mike > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 20, 2004 11:31 AM > To: Beehive Developers; Kyle Marvin > Subject: Re: Idea on "write only implementation" for control > > > > - 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). > > Yah, that's one of the primary hassles with code-generation > in general. I've seen it work nicely where you end up > generating AbstractFoo, which isn't intended to be edited, > but rather sub-classed. > > Basically, you get default no-op types of methods, and just > override in MyFoo as you need. This at least allows for nice > TDD-style of development. But I don't know how subclassing > would figure in with controls. > > > If you think I'm missing or misunderstanding something, > please let me > > know! Keep those ideas coming! > > I'm personally controls-ignorant aside from what Dan has > waved his hands about. Though, I'll be learning more m'self > over the next week or two as I work on docs for'em. > > -bob >
