On Saturday 20 March 2010 11:31:19 am Lars G. wrote:
The other one, of which I have not thought that much
yet, is that you can’t be 100% sure that #const_missing gets hit.
That was mostly my point, and the examples I used are cases where
const_missing isn’t hit.
if a class/module that uses #autoload defines its own #const_missing?
If they don’t do a proper alias_method_chain on it, that’s their own
Put another way: You’re allowed to redefine Fixnum#+, or NilClass#nil?,
number of other things. If you abuse this ability, you get to keep both
pieces. Even the authors of irb don’t plan for every contingency:
irb(main):001:0> class NilClass
irb(main):002:1> def nil?
match_io': undefined methodcall’ for
match' from /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:287:intoken’
lex' from /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:234:inblock (2
loop' from /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:230:inblock in
catch' from /usr/lib/ruby/1.9.1/irb/ruby-lex.rb:229:ineach_top_level_statement’
eval_input' from /usr/lib/ruby/1.9.1/irb.rb:69:inblock in start’
catch' from /usr/lib/ruby/1.9.1/irb.rb:68:instart’
from /home/ruby19/bin/irb:12:in `’
Btw, what’s this second braindead decision? I would be very interested
The behavior of UnboundMethod – you can only bind an UnboundMethod to
object of an appropriate class. So, for example:
umeth = Foo.instance_method(:bar)
What do you do with an UnboundMethod? Well, this is roughly how things
BlankSlate can hide/unhide methods – it removes all methods from an
and stuffs them into a hash, but you can have it re-apply those methods
kind of like this:
bmeth = umeth.bind(Foo.new)
Once it’s bound, you can call it:
Or shortcut the process:
Here’s the problem: In my mind, one of the cooler things about being
unbind methods like this is to allow the kind of free-for-all that you
the closure to reapply to the same object, or apply them directly to a
different object… Yes, you could do prototypal inheritance, but you
also do ad-hoc code reuse.
As an example, in Ruby, Object#extend and Module#include either are or
on very low-level constructs that aren’t really accessible to you. In
using the fact that methods are just functions that you apply to (or
to) a given object, and functions are themselves first-class objects.
In Ruby, this isn’t quite the case. Try something like this instead:
You get a TypeError. That’s very Java-like behavior. That’s
strict type-checking sneaking into an otherwise beautiful, dynamic,
language. It’s the polar opposite of duck-typing.
There may be performance reasons to do it this way, I’m not sure. (A
counterargument: How is Ruby doing versus Google’s v8 interpreter for
it’s never sane to do that, so I shouldn’t be able to. Erm, I can
Fixnum#+, you’ve got open classes, define_method, and eval, and you
me re-bind an existing method? Sorry, not buying it – I thought the
point is that it’s up to the programmer to decide what’s sane, and if
something insane, you get to keep both pieces.
I thought it was only languages like Java that try to keep you from
yourself in the foot by limiting your possibilities.
But I digress – I did find an ugly workaround for the project I needed
on, and that project has stagnated for awhile anyway. Still, it’s one of
few things that still bother me about Ruby.
(Another is that I really like Python’s significant indentation, and
prefer it to Ruby’s end-end-end-end. However, that’s a dead horse, and
seem to be entirely too many Ruby people who don’t want to see that even
become an option, and there’s too many other things I like about Ruby
one feature to send me back to Python.)