Hi Mike:

thank you for the comparison.

>From MIKEMIL@vnet.ibm.com Tue Dec 23 11:48:20 1997
>From: "Mike Miller"<MIKEMIL@vnet.ibm.com>
>To: lieber@ccs.neu.edu
>Subject: Re: Beans for Demeter
>
>As you requested, here's a brief comparision of the three JavaBean Aspect
>language projects completed for your class.
>
>Introspection vs Reflection
>--------------------------------------------
>Project one implemented the BeanInfo class, which was a very nice touch.
>Project two (mine) left the implementation of the BeanInfo class as a
>furture enhancement.  Projects two and three both decided that with a
>slight change in the existing Demeter/Java naming conventions, this part of
>the implementation would be automatically handled by Java.
>
>My recommendation would be to implement both.  By using the correct 'design
>pattern' that is defined in the JavaBean spec, there is no need to create
>the BeanInfo class.  Being good programmers also means providing the
>alternative to create the BeanInfo class if the developer wishes to.
>Implementing both, provides the best coverage for the Demeter/Java product.
>
>Property Support
>---------------------------------------
>All three projects provide some type of support for properties, although
>all at different levels.  Project two provided support for both Bound and
>Constrained properties, while project one and three only provided support
>for Bound properties.
>
>In order to provide a full implementation of JavaBean within the
>Demeter/Java product, you will need to implement support for both Bound and
>Constrained properties.
>
>Event Support
>-----------------------------
>Project two specified an implementation path for events, while the other
>projects only included the implementation as a future requirement.
>
>Summary
>--------------------
>Project two provided the fullest implementation for Java Bean in
>comparision to the other two projects.  The project addressed all of the
>major aspects required in order to create a fully functional JavaBean.  The
>project was not documented very well, but remember, I completed the project
>in 10 days( due to two weeks vacation and 3 days of additional work-related
>travel  during the timeframe allocated for work on the project).
>
>I think your team could very easily implement the JavaBeans aspect in to
>the existing Demeter/Java product by merging the work done by each of the
>projects.
>
>More recommendations
>-------------------------------------------
>After taking some more time to think through my implementation and review
>the other two projects, I believe there is a way to help simplify the
>JavaBean aspect langauge, no matter whose implementatin that you choose to
>implement.   I recommend that the engine determine whether or not to add
>what I called 'ListenerSupport'  to the target class.   The
>'ListenerSupport' was a block of code that is required for
>registering/unregistering listeners.   The engine should keep a track of
>class being processed and could keep a boolean flag for
>BoundPropertyImplemented and ConstrainedPropertyImplemented.  Once one of
>those types of properties is found, the flag is set and when the weaver
>output is generated, the flag indicates whether or not to write that block
>of code.   This helps encapsulate the listener support code and requires
>that the developer only specify whether a property is Bound or Constrained.
>By specifying that attribute, the engine will automatically generate the
>required code.  The same approach could be attempted with events but may
>require some extra work due  to the datatype type differences.  Property
>changes all use the PropertyChangeListener datatype but events will
>generally have a new data type of event listeners.
>
>
>