Bill Dortch wrote:
This will work almost as shown in the interface implementation I'm
working on. (Note: I've been away from it for a couple of days, will get
back to it in a day or so.) Here's what I'll submit for consideration
(open, of course, to debate/discussion):
Timing is critical here...we need to slam the door shut on any
additional major changes in the *very* near future.
And two things I noticed that probably need to be fixed for 1.0:
- Almost every place we get fields and methods from reflection it's
using "getFields" or "getMethods", when what we really want is
"getDeclaredFields" or "getDeclaredMethods" now that we're reflecting
the same hierarchy. That would be a big performance boost for big
hierarchies like Swing.
- Documentation and tests. We're adding a lot of capabilities and syntax
here and there's really only one person on the planet that knows what
works now and how to use it: you (Bill). We need to get a brain dump
from you onto the wiki about all the new syntax, and anything else
you've learned about this stuff. There's a t-shirt in it for ya.
And the rest of you should start dumping everything you know, however
disjointed and confuddled, into the wiki. We need lots of help here.
1. Current behavior (interfaces as Ruby classes) will be supported,
though (in my eyes, at least) deprecated. Existing code will continue to
function unmodified.
Continue to function, yes. Potentially deprecated in favor of other
mechanisms for implementing an interface? Thoughts you all?
2. Interface modules will be implemented. It will be possible to get the
class version from the module version, and vice versa.
I know we need the class version for the < extends syntax to work, but
it's sure a pain to have two types of object floating around. I know
people would tend to open up or try to work with the wrong one.
I almost think we should go straight to interfaces-as-modules rather
than have both types, but I have no good solution for how to make that
work with extension syntax.
3. When proxies are created for concrete Java classes and inserted into
the Rubified Java class hierarchy, the interface modules for any
implemented interfaces will be included into them (unless they've
already been included in a superclass). This will enable the behavior
you're looking for, as well as kind_of?, (class/module) A < B, etc.
Excellent, this is exactly what I was hoping for from the
interfaces-as-modules logic.
4. Multiple interfaces will be includable into new classes. For
original (non-generated) Java classes, the interfaces will be frozen; it
will _not_ be possible to open java.lang.Object and include, say,
java.lang.Runnable (though you can include non-Java modules). For
generated proxies, interfaces _could_ be frozen after the first
instantiation, though I'm not convinced this is necessary. (I'm open to
convincing, of course.)
It's what everyone wants, but I worry about the implications. Maybe I
shouldn't worry so much.
Basically, my problem with this is that if you want to add additional
modules in Ruby, you know that existing instances will reflect that new
behavior. However in Java, once the class/proxy has been created, we
can't add interfaces. Even if we defer the creation of the class/proxy
until later, the first instantiation would have to freeze it because
additional module additions are just not possible.
It may be possible to get around freezing, perhaps, by using appropriate
hooks in the module (append_features raising an error if the java proxy
has already been created?) or something similar.
Thoughts?
In your example, the only difference would be defining the execute
method in the Connection _module_, rather than the class:
module Connection::Includable
I assume this is because we have both classes and modules, to support
the < extension syntax. I'm not happy about that :( I want to just do
module Connection
...
end
Bugger.
(I've been working on an optimized variant of JavaProxyClass generation;
there's no reason that methods other than those overridden in Ruby
should be generated. It's kind of appalling (and, I believe, the source
of some problems) to see every (non-private) internal method call in,
say, a JFrame subclass routing through __jsend to the JavaProxy
callback, everything being converted to/from Ruby. Even when the user
isn't doing anything, as long as the Swing thread is running, this
process churns along.)
Yes, the amount of overhead in Java support is pretty awful. Anything
that can be done to reduce it (like your idea or getDeclaredMethods-type
changes) would be most welcome.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
