You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Berin Loritsch <bl...@apache.org> on 2002/10/03 16:40:57 UTC
[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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Juozas Baliuka <ba...@centras.lt>.
<snip>
> public class MyClass {
> private int fAge;
> private String fName;
>
> static {
> BeanInfoUtils.expose(MyClass.class, "name", "fName",
> "setNameWithValidation");
> BeanInfoUtils.expose(MyClass.class, "age", "fAge", "fAge");
> }
>
> private void setNameWithValidation(String name) {..}
> }
>
> Then, the properties can be accessed by PropertyUtils:
>
> PropertyUtils.setProperty(myObj, "name", "John Yu");
> PropertyUtils.setProperty(myObj, "age", new Integer(42));
>
> Comment?
As I see "MyClass" has no public methods and fields and "PropertyUtils"
must be used
to manipulate properties. I is meaningful if bean is used from some
scripting language,
but I do not like to type things like this in JAVA. I think the best
solution to implement some
compiler, like aspectj did.
<snip>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 4 Oct 2002, John Yu wrote:
> Now I understand we're actually talking about a thin wrapper of dynamic
> proxy. I second the idea. Even delegates and inner classes are semantically
> equivalent at the byte-code level, the "syntax sugaring" offered by C#'s
> delegates saves a lot of repetitive and verbose code.
>
> I haven't thought it through how this can be achieved in Java (and how to
> cleanly get around the security manager). But if we can doing the
> following, it'll be really cool:
>
> public class MyClass {
> private int fAge;
> private String fName;
>
> static {
> BeanInfoUtils.expose(MyClass.class, "name", "fName",
> "setNameWithValidation");
> BeanInfoUtils.expose(MyClass.class, "age", "fAge", "fAge");
> }
>
> private void setNameWithValidation(String name) {..}
> }
>
> Then, the properties can be accessed by PropertyUtils:
>
> PropertyUtils.setProperty(myObj, "name", "John Yu");
> PropertyUtils.setProperty(myObj, "age", new Integer(42));
>
> Comment?
My thing recently has been to use dynnamic proxies to do the
implementation and only code the interfaceas. Most of this has been in my
head, but I have a RandomBean structure that uses dynamic proxies to make
randmoised beans, and am gonna add a NullBean and BeanImpl pair. Then
you'd do:
Person person = (Person)BeanUtilsThing.createRandomBean( Person.class );
I can't however think of a way to not define the type and the get/set
methods [apart from code-generation pre-compile].
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by John Yu <jo...@scioworks.com>.
<soap-box>
I won't be surprised Java's introduction of Dynamic Proxy is an answer to
Hejlsberg's criticism.
I remember when C# was first introduced, there was this interview with
Hejlsberg who criticized Java's adaptor pattern and later Gosling responded
by calling Hejlsberg the "pointer man".
I tried to find the webpages but couldn't. The only thing I found on
java.sun.com is a white paper on "About Microsoft's Delegates [vs. Java's
inner classes]"
http://java.sun.com/docs/white/delegates.html
</soap-box>
Initially, when Berin said he wanted to "generate" delegates, I got the
wrongly impression Berin wanted to do code generation. (i.e. Doing what
AspectJ is doing now: introduce some new syntax at the language level and
do a pre-processing to speak out plain java code.)
Now I understand we're actually talking about a thin wrapper of dynamic
proxy. I second the idea. Even delegates and inner classes are semantically
equivalent at the byte-code level, the "syntax sugaring" offered by C#'s
delegates saves a lot of repetitive and verbose code.
This leads me to think of a related idea. I used to code in Delphi. In
Delphi, creating properties is declarative, not like the tedious and
verbose JavaBean setter/getter idiom. e.g.
type
TMyObject = class(TObject)
private
FName : String;
FAge : integer;
procedure SetNameWithValidation(Name: String);
property
Name : String read FName write SetNameWithValidation;
Age : integer read FAge write FAge;
Notice the flexibility of allowing binding either raw attributes or methods.
I haven't thought it through how this can be achieved in Java (and how to
cleanly get around the security manager). But if we can doing the
following, it'll be really cool:
public class MyClass {
private int fAge;
private String fName;
static {
BeanInfoUtils.expose(MyClass.class, "name", "fName",
"setNameWithValidation");
BeanInfoUtils.expose(MyClass.class, "age", "fAge", "fAge");
}
private void setNameWithValidation(String name) {..}
}
Then, the properties can be accessed by PropertyUtils:
PropertyUtils.setProperty(myObj, "name", "John Yu");
PropertyUtils.setProperty(myObj, "age", new Integer(42));
Comment?
--
John
At 03:02 am 04-10-2002, you wrote:
>Steve Downey wrote:
>> From
>> http://msdn.microsoft.com/library/en-us/dndevqa/html/msdn_andersh.asp,
>> an interview with Anders Hejlsberg, the original architect of Borland's
>> Delphi, regarding some of the work he had done for the "Windows
>> Foundation Classes", part of Microsoft's J++ product, after he jumped
>> ship from Borland.
>>His work was later adopted into C#.
>
><snip type="article"/>
>
>That was a very interesting read. I'm sold on Delegates as a way of
>doing things. We basically did the only thing we could do without
>extending the language--although it would be nice to have a JSR for
>this puppy.
>
>I tell you, it will make it alot easier for certain GUI apps....
>
>myButton.addActionEventListener(
> Delegate.newDelegate(
> this, "handleMyButton", ActionEventListener.class ) );
>
>And the logic goes in a method:
>
>public void handleMyButton( ActionEvent event )
>{
> // perform logic
>}
>
>And that's without modifying Swing!
--
John Yu Scioworks Technologies
e: john@scioworks.com w: +(65) 873 5989
w: http://www.scioworks.com m: +(65) 9782 9610
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Berin Loritsch <bl...@apache.org>.
Steve Downey wrote:
>>>From http://msdn.microsoft.com/library/en-us/dndevqa/html/msdn_andersh.asp, an
> interview with Anders Hejlsberg, the original architect of Borland's Delphi,
> regarding some of the work he had done for the "Windows Foundation Classes",
> part of Microsoft's J++ product, after he jumped ship from Borland.
>
> His work was later adopted into C#.
>
<snip type="article"/>
That was a very interesting read. I'm sold on Delegates as a way of
doing things. We basically did the only thing we could do without
extending the language--although it would be nice to have a JSR for
this puppy.
I tell you, it will make it alot easier for certain GUI apps....
myButton.addActionEventListener(
Delegate.newDelegate(
this, "handleMyButton", ActionEventListener.class ) );
And the logic goes in a method:
public void handleMyButton( ActionEvent event )
{
// perform logic
}
And that's without modifying Swing!
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Steve Downey <st...@netfolio.com>.
From http://msdn.microsoft.com/library/en-us/dndevqa/html/msdn_andersh.asp, an
interview with Anders Hejlsberg, the original architect of Borland's Delphi,
regarding some of the work he had done for the "Windows Foundation Classes",
part of Microsoft's J++ product, after he jumped ship from Borland.
His work was later adopted into C#.
It was also a key point in Sun's complaints about the MS Java implementation,
because they introduced a keyword 'delegate' to implement it, as dynamic
proxies were not available. Also, as a language feature, MS's delegates could
be statically checked against method signatures at compile time.
<quote>
MSDN: Can you describe the new eventing model in WFC, which uses something you
call delegates?
Hejlsberg: The technically correct term for delegates is "bound method
references." If you think about the ActiveX or JavaBeans eventing models,
they both use interfaces for eventing. We use delegates, or bound method
references.
For example, in the ActiveX or JavaBeans world, if you have a button that
wants to fire an event, it does so by defining an interface. Someone has to
implement that interface and then give it to the button so the button can
call back on that interface, in order to fire events.
In the WFC component model, a button essentially has a bound method reference
that it calls when you click on the button. You don't have to implement an
interface in order to receive the event. You simply have to supply an object
and a method and say to the button, "When you're clicked, just call this
method on this object." So it's a simpler model. It's also a more flexible
model.
If you look at how JavaBeans tools today implement eventing, they have a
problem. Let's say you have a form that has 100 buttons on it, and you want
to have a separate event handler for each button. Now you need to implement
this event interface 100 times, but you can't, you can only implement that
interface once.
You're faced with either having to write 100 adapter classes--that is, little
classes that each implement the button interface and then forward it to the
particular event handler--or you have to write one handler that has a
gigantic switch statement that switches on the sender of the event.
You're either trading a lot of space away, because classes are fairly big in
footprint, or you're trading speed away. But with the WFC delegate model,
you're not trading anything away.
The other thing that's interesting about delegates--and particularly how we
implemented delegates --is that we can do automatic multicasting of events. A
control that fires an event sees essentially one bound method reference, one
delegate that it calls to. That delegate will (underneath the hood)
potentially call many receivers of the event. This all happens automatically,
and with great efficiency.
Another thing that's interesting about delegates is they allow you to do
many-to-one mapping of event handlers. Because you're just referencing
methods, you can have a button click and a menu click both go to the same
event handler. You don't have to write these things that forward the call to
a common routine.
Finally, the thing that's interesting about delegates is that they make it
very easy to do dynamic routing of events. This is particularly interesting
when you're doing data-driven instantiation of forms, where you read the
database, figure out what fields you want to present, and then dynamically
instantiate a bunch of edit controls or whatever. Then you bind their events
so you can update the data that underlies them.
Our delegate-based eventing model makes it very easy to do this. It's as easy
to attach an event handler to a UI control as it is to modify a property. So
there are many interesting advantages to delegates.
</quote>
On Thursday 03 October 2002 01:30 pm, Berin Loritsch wrote:
> Steve Downey wrote:
> > Only if you can explain why this version is NOT the same as the "evil",
> > "destructive", <choose your own negative adjective> one that Microsoft
> > implemented in J++.
>
> Uhmm, you'll have to tell me what you mean by that. I am not familiar
> with J++ variances with the Java spec.
>
> We use JDK 1.3 dynamic proxies to put the implementation behind an
> interface with only one method. You interact with that interface,
> even though the underlying object/method combo does not have to have
> the same name (although the rest of the signature has to be the same.
>
> It also works with Static Methods without requiring a public
> constructor!
>
> > Or maybe people have forgotten that by now.
>
> I've *never* been exposed to it.
>
> > For the record, I thought they were a good idea when Anders first
> > introduced them. They were a lot cleaner than the cruft introduced by
> > AWT.
>
> Exactly!
>
> > I think there's likely some synergy between this and some of the
> > proposals floating around for reflection utilities.
> >
> :)
>
> We have two versions of a Delegate:
>
> Delegate--An interface with one declared method that can return a value.
> the implementation of the method can be a static method or an
> object instance method as long as the parameters/return value/
> exception clauses are compatible.
>
> MultiDelegate--Similar to a Delegate except for the restriction that it
> cannot return a value. It is used for event
> notifications. One method call (like notifier.fire())
> can encapsulate calls to a whole set of delegates.
>
> The source code is in Excalibur Util CVS right now. We are shaking out
> the bugs/fixing up the javadocs and will most likely be done either
> today or tomorrow.
>
> If you are interested, take a look.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Berin Loritsch <bl...@apache.org>.
Steve Downey wrote:
> Only if you can explain why this version is NOT the same as the "evil",
> "destructive", <choose your own negative adjective> one that Microsoft
> implemented in J++.
Uhmm, you'll have to tell me what you mean by that. I am not familiar
with J++ variances with the Java spec.
We use JDK 1.3 dynamic proxies to put the implementation behind an
interface with only one method. You interact with that interface,
even though the underlying object/method combo does not have to have
the same name (although the rest of the signature has to be the same.
It also works with Static Methods without requiring a public
constructor!
> Or maybe people have forgotten that by now.
I've *never* been exposed to it.
> For the record, I thought they were a good idea when Anders first introduced
> them. They were a lot cleaner than the cruft introduced by AWT.
Exactly!
> I think there's likely some synergy between this and some of the proposals
> floating around for reflection utilities.
:)
We have two versions of a Delegate:
Delegate--An interface with one declared method that can return a value.
the implementation of the method can be a static method or an
object instance method as long as the parameters/return value/
exception clauses are compatible.
MultiDelegate--Similar to a Delegate except for the restriction that it
cannot return a value. It is used for event
notifications. One method call (like notifier.fire())
can encapsulate calls to a whole set of delegates.
The source code is in Excalibur Util CVS right now. We are shaking out
the bugs/fixing up the javadocs and will most likely be done either
today or tomorrow.
If you are interested, take a look.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Steve Downey <st...@netfolio.com>.
Only if you can explain why this version is NOT the same as the "evil",
"destructive", <choose your own negative adjective> one that Microsoft
implemented in J++.
Or maybe people have forgotten that by now.
For the record, I thought they were a good idea when Anders first introduced
them. They were a lot cleaner than the cruft introduced by AWT.
I think there's likely some synergy between this and some of the proposals
floating around for reflection utilities.
On Thursday 03 October 2002 10:40 am, Berin Loritsch wrote:
> 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?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Delegates was Proposal for *NEXT* version
Posted by Berin Loritsch <bl...@apache.org>.
Stephen Colebourne wrote:
> Split the thread as this bit got lost...
>
> There are definite similarities between this Delegate description and the
> code that is currently located in [pattern]. [pattern] contains four simple
> callback interfaces Predicate, Transformer, Command and Factory. It also has
> methods that support calling back to an arbitrary method using reflection.
>
> Delegates take the approach of allowing any interface and calling back using
> reflection.
> The [pattern] case limits the interfaces to specific ones.
> Otherwise they are similar.
>
> There is a lot that can be done with delegates/BCEL/advanced beans. I would
> really like to start getting this together, but I think that its a new
> project [clazz] that builds on [lang].
>
> Stephen
If we can throw together delegates and generic meta-info I would pass out
with joy... Those two features are becoming necessities in Avalon land.
We are attempting to work with meta-info using component descriptors--but
a more generic approach would be better IMO.
Anyway, what else do you want to include with Delegates?
BTW, the code is in place and works quite well. The only issue is that
I would like to have a MultiDelegate that returns a Delegate capable
interface return a MultiDelegate. Example is this:
Agent agent = (Agent) Delegate.newMultiDelegate( Agent.class );
// Add new listeners:
((MultiDelegate) agent).add( otherAgent1 );
((MultiDelegate) agent).add( otherAgent2 );
// Get the result:
Action action = agent.findAction();
// Use result:
action.perform();
(If you are wondering what that is all about, I am working on putting
together a framework for Intelligent Agents.)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Delegates was Proposal for *NEXT* version
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Split the thread as this bit got lost...
There are definite similarities between this Delegate description and the
code that is currently located in [pattern]. [pattern] contains four simple
callback interfaces Predicate, Transformer, Command and Factory. It also has
methods that support calling back to an arbitrary method using reflection.
Delegates take the approach of allowing any interface and calling back using
reflection.
The [pattern] case limits the interfaces to specific ones.
Otherwise they are similar.
There is a lot that can be done with delegates/BCEL/advanced beans. I would
really like to start getting this together, but I think that its a new
project [clazz] that builds on [lang].
Stephen
From: "Berin Loritsch" <bl...@apache.org>
> 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?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Berin Loritsch <bl...@apache.org>.
TJames Strachan wrote:
> 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.
THat's the general idea.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Henri Yandell <ba...@generationjava.com>.
Obviously one big issue floating under the surface in all this is the 1.3
nature of dynamic proxies.
>From my position in the audience, BeanUtils appears to be flying towards
1.3 dependency as it has so many cool new beanie proxy things that could
go in, and I'm sure Lang will be facing it sooner rather than later.
Hen
On Fri, 4 Oct 2002, James Strachan wrote:
> 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" <bl...@apache.org>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
> __________________________________________________
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by James Strachan <ja...@yahoo.co.uk>.
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" <bl...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
__________________________________________________
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Proposal for *NEXT* version
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
<snip>
> 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?
It was discussed on this list and we decided to setup some new subpoject
for reflection. I think "delegate generator" is very good for this project.
I forked some code from sandbox and it is hosted on http://cglib.sf.net
at this time, I am going to propose some "code geneation" ideas for
[reflect] project too.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>