On 4/26/07, Charles Oliver Nutter <[EMAIL PROTECTED]> wrote:
Timing is critical here...we need to slam the door shut on any
additional major changes in the *very* near future.
Yep, should be wrapped up over the weekend.
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.
The problem is that right now, if a class defines method, it becomes
responsible for all the methods with the same name (even if they're
implemented in a superclass), in order to do matching_methods. It _might_ be
possible to optimize this by getting the superclass's callback hash
(possibly searching up the chain to java.lang.Object), but then you'd have
to check for every method, because you can't really tell if a method
overrides/overloads a superclass version. In the end, I don't know if it
would be any faster; it might actually be slower.
I think we got a pretty good performance benefit by not defining any methods
(in Ruby) that are not declared in the current class. A
javax.swing.JFrameproxy, for example, doesn't define any of the
(numerous)
java.awt.Component methods unless it overrides/overloads them. So once
certain key classes are loaded (java.awt.Component, javax.swing.JComponent,
javax.swing.AbstractButton), everything else should load pretty fast.
- 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.
Yep, on my agenda for next week, though some of the more arcane stuff might
get filled in over time.
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.
I can't make a module work with class extension syntax, there's no hook for
it that I'm aware of. I can do the reverse by hooking #include, but that
doesn't help here. (I looked at exposing classes only, and silently
converting to modules where needed; you can do it with #include, but not
#kind_of?, A < B, etc. And I think allowing classes in #include will draw
protests (or at least dirty looks) from the Ruby community.)
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.
Here's some murky water. You could _not_ freeze; existing instances already
have their copy of the generated proxy class; a new proxy class could be
generated and used by subsequent instances. But yes, this does go against
the usual expectations in Ruby. Dirty looks and snickers again. Still, if
this is what a user wants, then why not?
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.
Agreed. Double 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
