RE: addJavaBeanMethods

The other way to go with Java bean compatibility is to generate
"BeanInfo" classes for Scala classes.  This is probably the way to go,
although slightly more involved.  There's no possibility of collision
between function names and more information can be specified.  With
attributes on Scala classes that are standardized we can attach
descriptive information (like text, icon, etc) to properties and
generate the "right" thing on different platforms (.NET and JVM).

Given appropriate attributes the code generator would write a class that
assembles property descriptors, method descriptors, etc.  The nice thing
about the descriptors is that you can specify the method to call
directly, and no naming convention is necessary.

RJ

-----Original Message-----
From: Nikolay Mihaylov [mailto:nikolay.mihaylov@xxxxxxx] 
Sent: Friday, February 10, 2006 4:22 PM
To: joel@xxxxxxxxxxxx
Cc: scala@xxxxxxxxxxxxxx
Subject: Re: addJavaBeanMethods

On Fri, 2006-02-10 at 08:27 -0800, joel@xxxxxxxxxxxx wrote:
> I'd definitely vote to have it capitalize the initial character. That 
> would certainly be the Java way, and this is intended purely for Java
anyway.

We could have a separate attribute that does the same as BeanProperty
but with capitalization. I'm just kidding. But once you get locked in a
serious attribute collection, the tendency is to push it as far as you
can...

Seriously, what you suggest is easy to arrange. But I'm having seconds
thoughts on the way I implemented it. My primary concern is what happens
if, say, getMyProperty already exists. Obviously, we cannot introduce
new methods without making sure we're not stepping on someone else's
toes. This should be handled as early as possible. In any case, I don't
think the code generator should perform any lookups.