Dave Burt
5/30/2006 7:18:00 AM
Mark wrote:
> ... I am aware of method()
> but that hardly cuts it IMO. Wrapping second-class entities in first
> class ones doesn't make them first class, if anything it's a very cute
> hack to solve a problem that wouldn't exist otherwise.
It's not a hack, it's simply a different paradigm. Ruby is not primarily
a functional language, it's primarily object-oriented.
If all you want is to be able to refer to a method as "obj.method_name"
rather than "obj.method(:method_name)", Ruby will never let you, because
(in an OO language) we prefer calling methods to passing them around as
functions, and so the simple syntax is reserved for that.
Of course, there's no reason to my mind why the syntax "obj::foo" might
not be syntactic sugar for "obj.method(:foo)" in the same way as "for"
is for "each". There's still absolutely no reason the Method should be
reified before such a call.
Your assertion that Object#method is "wrapping second-class entities in
first class ones" is ridiculous. It is that in exactly the same sense as
procs, integers, classes and all other Ruby objects are. A first-class
entity is simply one that's accessible as an Object instance, and a
Method instance is that.
> You say that Method objects can be used pretty much interchangeably
> with Proc, and the same can be said about Lambda. So what, you have is
> three slightly different entities that do the same thing at the
> implementation level :(.
Two: Method and Proc.
(lambda {}).class #=> Proc
Why is this a bad thing? Would it be better if they were incompatible?
In an object-oriented language, we need methods (bound to instances);
and unbound functions (procs, blocks) are useful as well -- it's just a
different way to create a (first-class) function.
If you do really want just one, you can easily make a Proc that calls a
method:
f = proc {|*args| obj.foo(*args) }
> Replacing methods (second class citizens) with objects (first class
> citizens) would remove this complexity and make Ruby more flexible.
> Someone please tell me how that could be a bad thing and why you
> wouldn't want it?
First, please tell me why it's a good thing and why you do want it.
As I said, obj.method(:foo) gives you exactly the first-class object you
want.
> It's just something that I'm less than happy with and it should be
> taken as personal opinion. It's about the only thing in Ruby that I'm
> REALLY not happy about; it's obviously a win for everything in a
> language to first class. Overall, Ruby is a very nice language.
That's fine, of course, but I think you're missing something if it irks
you that much.
> I have to say that if this is done for performance reasons then it's a
> bad case of premature optimization. There are languages that do have
> first class methods and are much faster than Ruby, it has to be a bad
> design choice to disable the language in order to solve implementation
> problems which I'm sure will be resolved in due course :).
>
> It's a poor excuse no, I doubt that's Matz reason.
What languages have "methods are objects" as you're proposing and are
faster than Ruby?
Anyway, although the performance cost of reifying methods is definitely
a factor, another one (I'm still not sure exactly what you want here)
might be syntax. As I said above, maybe what you want here is for the
method call syntax to be co-opted into producing a reference to your
method object, and that's not going to happen. "obj.foo" calls the foo
method.
> Personally I'd prefer to use a slightly slower language that lets me do
> some very powerful and interesting things easily. Ruby as it exists now
> doesn't strictly hinder, but it does make some things very unclear.
> ...
> Making this change in Ruby would make for a better synergy between the
> two approaches.
Exactly what things does it make "very unclear"?
Exactly what change are you after? Re-reading your first email, it seems
you just want a Method object. We have that already.
Why not post some Ruby code you don't like, and the syntax you would
like to use to accomplish the same task, and the accompanying semantics?
> Either way I take it that Ruby will never fix this? Or it isn't on
> the bill for Ruby 2.0?
I still don't see what needs fixing, or how you're proposing it be fixed.
Cheers,
Dave