Bill Dortch wrote:
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.JFrame proxy, 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.
You might be right here. I'll defer to your judgment since I haven't
looked at this code in depth.
I still think there's a lot of benefit to a total Java support internals
redesign after 1.0, so this could easily be deferred.
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.)
We definitely can't allow include to accept a class, that would
definitely be frowned upon.
What are the implications of altering the simple extension syntax? It's
only still there for interfaces because it was the classic way...but it
doesn't really make sense, since you're not extending the interface. If
we want to make the hard change, we damn well better make it before 1.0
is released.
If Bill and others are able to convince those of us afraid of
interfaces-as-modules, the following would be the new way to implement a
single interface:
class MyClass
include List
end
...and the < syntax would go away, reserved ONLY for extending a class.
I dunno...the problems with interfaces on the extends line push me one
way and the implications of interface modules push me another way.
So a few truths:
- the extends syntax is neat, but weird when thinking about interfaces;
I bet people could get used to not having it, especially with things
like MyInterface.impl.
- the module syntax for interfaces sure is nice, if you can ignore the
fact that we can't actually add interfaces to proxies after the fact,
nor add interfaces to already-generated objects.
- it's really ugly and sucky to have both a class and a module in memory
for a given Java interface. Really sucky. But at the moment it doesn't
seem like there'd be another way.
I'm not sure trading backward-compatibility with the extends syntax is
worth losing the following beautiful syntax:
module List
def do_something_crazy
...
end
end
...and having it magically apply to all List-implementers in the system.
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?
Maybe. I'm either starting to be swayed or too tired to think of why
this doesn't work.
- Charlie
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
