Ruby.extend Javascript

Ruby
1

Doing some Javascript coding today and started to wonder about it’s
open objects. If it works so well for Javascript, then why not Ruby
too? So I threw this together:

Add open_accessor.

class Module
private
def open_accessor®
class_eval %{
def #{r}=(v)
o = (class << self; self; end)
if Func === v
o.send(:define_method,:#{r}, &v)
else
o.send(:attr_reader, :#{r})
@#{r} = v
end
end
}
end
end

All objects are open.

class Object
def method_missing( s, *a, &b )
w = s.to_s
if w[-1,1] == ‘=’
r = w.chomp(’=’)
v = a[0]
o = (class << self; self; end)
o.send(:open_accessor, r)
send(w,v)
else
super
end
end
end

Func is a Proc, but we need a distinction to determine

when one represents a new method vs passing a proc as object.

class Func < Proc
def to_proc
Proc.new(self)
end
end

Create a new object of +classification+.

def obj(classification=Object)
classification.new
end

Define a function.

def fn(&b)
Func.new(&b)
end

Show off.

if $0 == FILE

o = obj()

o.a = 1
p o.a

o.b = fn{ puts "hello" }
o.b

end

So would Ruby benefit from being able to do this inherently? Or are
there reasons against it and it is actaully Javascript that’s suffering
for it? Or is there some difference between Ruby and Javascript that
makes it good for one, but not the other?

T.

2

Trans wrote:

Doing some Javascript coding today and started to wonder about it’s
open objects. If it works so well for Javascript, then why not Ruby
too? So I threw this together:

o = obj()

there reasons against it and it is actaully Javascript that’s suffering
for it? Or is there some difference between Ruby and Javascript that
makes it good for one, but not the other?

T.

Javascript is a prototype based language where prototype is a template
for objects, Ruby on the other side is a class based language. It’s
nothing wrong with Javascript,IO,Self and others:
http://www.dekorte.com/docs/protos/ or Ruby - they just represent
different paradigms. But there are analogies as well:

function Obj(){
}

Obj.prototype = {
attr : 7,
method : function(){
print(“hello!”)
}
}

The Obj prototype holds an associative array for new objects, so:

obj = new Obj()
obj.method()

and this is pretty much an equivalent of a class based approach Ruby
offers

but when:

obj.method = function(){
print(“hello2”)
}

obj.method()

will print hello2. The method attribute in object obj now hides the
original one (the one in prototype object)

btw. This works pretty much the same in Python (there are dictionaries
called dict that hold attributes for classes and instances
respectively).

Ruby provides the same functionality using singleton objects

class Obj
def method
p “hello”
end
end

obj = Obj.new

obj.method

and then:

class << obj

 def method
     p "hello2"
 end

end

obj.method

the method method is now being hold in the singleton class (the one
you access by (class << self; self; end) )

there is also an implementation of a prototype-based Ruby sublunguage
called sloop:
http://chneukirchen.org/blog/archive/2006/08/sloop-sublanguage-for-object-orientation-with-prototypes.html

lopex

3

there is already a prototype library you can try out
http://rubyforge.org/projects/codeforpeople/

4

Trans wrote:

So would Ruby benefit from being able to do this inherently? Or are
there reasons against it and it is actaully Javascript that’s suffering
for it? Or is there some difference between Ruby and Javascript that
makes it good for one, but not the other?

It’s the expected way of doing things in prototype-based OO - a class
definition is sum of method additions to its parent prototype.

Ruby is mainly a class-based OO language, which means readers of the
code expect to see class definitions, not prototype manipulations.

It is generally possible to implement a class-based object system in a
prototype-based language and the other way around, but generally other
users of a language will easier understand code written in a language’s
primary flavour. Also, that flavour will probably be more efficient
because it gets first-class support (and is usually the flavour
implemented in C these days.)

There’s nothing inherently “wrong” about using prototype-style OO in
Ruby while heavily abusing singleton methods or automagical delegates,
but it will confuse people reading that code. There’s also no RDoc
support for sniffing that code structure, and various other quirks. But
it’s a valid approach in my book.

David V.

5

Marcin, David, greg thanks for the feedback.

I’m more interested in the question as to why having that capability
directly built-in would or would-not be of benefit to Ruby.

I’m aware of the class vs. prototype differences and ara’s
implementation of prototype.rb --i’ve even written one myself years ago
(sloop was new to me though thanks). And granted, we could use such a
lib even if it were a tad suprising to on looking Ruby coders. But I’m
not really looking at a whole prototype approach so much as just
thinking that this one particular capability would be of use. And the
reason I say that, is that I find myself more and more often using
hashes for parameters rather than straight arguments. In turn I usually
prefer accessing them with dot notation rather than hash, so I end up
doing:

def foo( keys )
keys = keys.to_openobject
keys.bar
keys.baz
…

(OpenObject is an improved OpenStruct BTW) There’s a lot of overhead
going on here. So when I was working with Javascript today, I couldn’t
help but think, why do they have it so good in this respect, but Ruby
doesn’t?

T.