The initialize collision is really just one case of method collision.
Initialize might act like its super special, but you could redefine
new() to use something completely different then initialize, at which
point initialize isn't special, even in vanilla Ruby.

I think whatever choice is made should also apply to any other method
which already has expected behavior in Ruby: e.g. if a Java class
defines to_s() and toString(), we map toString() to to_s, but what do we
map to_s to?  My vote goes for something like obj.send_java(:method,
*parameters), since that way we can eliminate the possibility of further
collision.  This makes the Java object act less like a Ruby object, but
there's nothing all that unexpected about that.

Evan

Charles O Nutter wrote:
> This is definitely a tricky one. In the java world we don't have to
> worry about constructors colliding with methods; however we obviously
> have that issue here.
> 
> I believe we should think about this from the perspective of the ruby
> script that would eventually call against the interface. It would be
> extremely unusual for a ruby script to be calling initialize directly,
> under any circumstances. Because it's typically protected, it's simply
> not done. By that logic, I think we should not allow initialize to
> propagate from the Java interface to the callable set of methods on the
> proxied Ruby object. I don't think it would feel right (and it would
> complicate the process of defining proxies' initialize methods across
> the board).
> 
> So then we need a way to map the Java interface's "initialize" to
> something callable in Ruby. I don't have any good ideas for this one yet.
> 
> On 5/14/06, * David Corbin* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
>     I ran across a problem today.   I was implementing a Java interface
>     in Ruby.
>     The interface had an method "initialize(...)" defined in it.  This
>     creates a
>     quandry, of course, because the initialize method is used during
>     construction.
> 
>     I'm not sure what the right solution for JRuby is. Ideas?
> 
>     I suspect you could write a ruby implementation that implmented
>     initialize
>     "smartly enough" to double as a ruby initialize, and as the interface
>     implementation but you shouldn't have to.
> 
>     David
> 
> 
>     -------------------------------------------------------
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
>     _______________________________________________
>     Jruby-devel mailing list
>     Jruby-devel@lists.sourceforge.net
>     <mailto:Jruby-devel@lists.sourceforge.net>
>     https://lists.sourceforge.net/lists/listinfo/jruby-devel
> 
> 
> 
> 
> -- 
> Charles Oliver Nutter @ headius.blogspot.com <http://headius.blogspot.com>
> JRuby Developer @ jruby.sourceforge.net <http://jruby.sourceforge.net>
> Application Architect @ www.ventera.com <http://www.ventera.com>


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel

Reply via email to