On Fri, 4 Oct 2002 [EMAIL PROTECTED] wrote:
> Date: Fri, 4 Oct 2002 10:16:19 +0100 (BST)
> From: [EMAIL PROTECTED]
> Reply-To: Jakarta Commons Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: [lang] Proposal for *NEXT* version
>
> Amazing...
>
> We're starting to discuss stuff I've been experimenting with all year. My own Joda
>project started initially as a way to generate beans from interfaces, adding in other
>facilities like support for Maps and Lists, plus event handling.
>
> If I had the chance then I would agree that the declaritive style of defining
>properties is preferable.
>
> public class Person {
> property surname String;
> property age int;
> }
>
> The trouble with this is that it requires source code pre generation. The only
>alternative I've thought of is to write something like an Eclipse plugin that hides
>the precompilation going on.
>
> Doing something better with beans/properties seems to be a repetitive requirement.
>So I'm fully supportive of looking at it.
>
The DynaBean abstraction (in BeanUtils today) lets you "synthesize" beans
with a dynamic set of properties -- although only PropertyUtils knows how
to do property get/set calls transparently for you. In Struts, for
example, we take an XML-ized version of a description like your Person
declaration above:
<form-bean name="Person">
<form-property name="surname" type="java.lang.String"/>
<form-property name="age" type="int"/>
</form-bean>
and construct a form bean that Struts uses to capture the incoming data
from an HTTP request, without having to manually create a new class. Does
this address some of the needs that lead you down this path?
> Stephen
Craig
>
> > from: James Strachan <[EMAIL PROTECTED]>
> > date: Fri, 04 Oct 2002 07:17:40
> > to: [EMAIL PROTECTED]
> > subject: Re: [lang] Proposal for *NEXT* version
> >
> > This all sounds great stuff.
> >
> > It mirrors recent blog conversations on adding some other C# features,
> > namely accessing class attributes (which are implemented as javadoc tags
> > right now but could use JSR175 later on when we move to JDK1.5).
> >
> > There's links to the various posts on the matter here...
> >
> > http://www.brainopolis.com/roller/page/lance/20021003
> >
> > It'd be nice to unify this stuff into a small reusable library.
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> > ----- Original Message -----
> > From: "Berin Loritsch" <[EMAIL PROTECTED]>
> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
> > Sent: Thursday, October 03, 2002 3:40 PM
> > Subject: [lang] Proposal for *NEXT* version
> >
> >
> > > The Avalon team has learned how the language features of C# can help us
> > > write better and more intelligent software. However, since none of us
> > > really has the money or inclination to completely tie ourselves to C#
> > > or M$, we want to add language features in a Java way.
> > >
> > > We threw together a way to generate Delegates. A delegate is like a
> > > method pointer, but it is also able to be treated like an Object. The
> > > benefit of this is that we can pass in the delegate to a method, and
> > > change the behavior of that method substantially.
> > >
> > > The perfect example where this pays off is with Intelligent Agent
> > > design. The Intelligent Agent is the building block of artificial
> > > intelligence. There are four or five basic algorithms for searching
> > > through a problem space to find the best solution. These algorithms
> > > require you to pass in functions. Delegates make all this possible,
> > > without forcing the original class to have the same name. For example:
> > >
> > > interface NewComparator
> > > {
> > > int compare( Object orig, Object other );
> > > }
> > >
> > > class ComparitorHeaven
> > > {
> > > public int compareClassName( Object orig, Object other )
> > > { /* implementation */ }
> > >
> > > public int compareEquals( Object orig, Object other )
> > > { /* implementation */ }
> > > }
> > >
> > > With the two declarations above, I can write a search algorithm
> > > like this:
> > >
> > > public Object findBestObject( String method )
> > > {
> > > ComparatorHeaven ch = new ComparatorHeaven;
> > >
> > > NewComparator checker =
> > > (NewComparator) Delagate.newDelagate( ch, method );
> > >
> > > Iterator it = m_myList.iterator();
> > > Object prev = it.next();
> > >
> > > while( it.hasNext() )
> > > {
> > > Object curr = it.next();
> > > int preference = checker.compare( curr, prev );
> > >
> > > prev = curr;
> > > // perform actual decisions based on preference
> > > }
> > > }
> > >
> > >
> > > We have some initial stuff checked in to Excalibur Util.
> > > When we are done shaping it up, we would like to give it
> > > to Commons Lang. I realize you are getting ready to make
> > > a release, which is why I don't want to push it for this
> > > release. What are y'alls thoughts?
> > >
> > >
> > > --
> > >
> > > "They that give up essential liberty to obtain a little temporary safety
> > > deserve neither liberty nor safety."
> > > - Benjamin Franklin
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Everything you'll ever need on one web page
> > from News and Sport to Email and Music Charts
> > http://uk.my.yahoo.com
> >
> > --
> > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
> >
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
