From: David Masover <ninja@...>
Date: 2010-04-28T12:50:28+09:00
Subject: Re: DrX, an object inspector

On Monday 26 April 2010 10:04:04 am Charles Oliver Nutter wrote:
> On Sun, Apr 25, 2010 at 3:23 PM, David Masover <ninja@slaphack.com> wrote:
> > On Sunday 25 April 2010 02:41:07 am Charles Oliver Nutter wrote:
> >
> > I've raised this question before, and people seem to disagree with me, 
but:
> >> # changing the object's class(!?)
> >> class Foo; end
> >> p obj.class # => 'Object'
> >> obj_ref.setMetaClass(JRuby.reference(Foo))
> >> p obj.class # => 'Foo'
> >
> > I think it should be possible to do that from within Ruby.
> >
> > But I can't even get most people behind this suggestion:
> >
> > class A; end
> > class B; end
> > A.instance_method(:to_s).bind(B.new)
> >
> > That gives me a type error, which just seems bizarre, especially after
> > the relative freedom of JavaScript. Ah, well.
> 
> The main issue that comes up with this is that classes with native
> methods (like all the core classes) would have to be given special
> treatment. You couldn't, for example, rebind a String method to Array
> or an Array subclass since the in-memory structure is different. In
> short, you'd at best end up with methods that don't function because
> they're not attached to an array, and at worst with methods that
> outright segfault.

I think I'm OK with that. JavaScript doesn't allow rebinding native methods, 
either. I would, however, strongly encourage fewer native methods when 
possible -- doesn't Kernel#autoload _still_ use a native call to the native 
require, thus bypassing any attempt to overload Kernel#require?

> There's no technical reason you couldn't allow rebinding of Ruby
> methods though.

Just a political one, I think. Every time I bring this up, I get a weak 
justification that seems to be based around some desire for strong, static 
typing, and strict, rigid inheritance. 

It's especially frustrating when, as in my example above, I'm trying to rebind 
a method which was originally declared on a parent class to both methods. 
Having to figure out (or programmatically navigate!) the class hierarchy to 
find the exact point which is a superclass (or supermodule) of both objects 
I'm working with, yet still has the appropriate method, and then rebind it all 
the way down the hierarchy, rather than at least having it Just Work 
(A.instance_method(:to_s) should return Object#to_s unless I actually define 
A#to_s), is the exact POLAR OPPOSITE of duck typing, do-what-I-mean, beautiful 
code, and everything Ruby is supposed to be about. Let me decide if the class 
is important -- if I really care, I can check obj.kind_of?(umeth.owner), but 
there's no good reason for the language to make that decision for me! Ruby is 
not supposed to be like Java!

*deep breaths*

I can definitely think of a few places where this would be useful. I can 
probably hack around it anyway, though -- it mostly just offends the purist in 
me. It is, IMO, the ugliest thing about Ruby's otherwise-beautiful object 
model.

> That's roughly possible in JRuby if you go "under the
> covers"
[snip]
> ...of course, the devil's in the details.

As much as I like JRuby, I'd much prefer a portable solution. However, I 
needed this for a project I've all but abandoned, so I'm not particularly 
motivated to write such a solution. (I'd guess the closest I would get is a 
single gem that does different hacks in different interpreters.)