G
George Ogata
David A. Black said:I'd rather not have a warning in the general case (i.e., imposed by
the interpreter rather than by the method's own logic). One might
have something like:
def x
@cached ||= yield * 10
end
where the yielding happens conditionally. (Classically non-wonderful
example, but still
Well, that's what I meant by:
I guess it doesn't due to [...] ruby's dynamic nature (it can't
determine for itself whether or not a block might be needed at
compile time, and it's inefficient to check it at runtime)
In your example, it *could* actually see that there's a "yield" node
in the AST, but with things like #eval it's impossible. (So it's
actually impossible at runtime too -- oops.)
So since the interpreter can't figure it out on it's own, you'd need
to give it a kick by providing some syntactic signal, e.g.:
def x & # the '&' means "I can take a block"
## ... maybe yield ...
end
....but then ruby has a
So in the end all I'm saying is that in an Ideal Magical World of
Happiness (TM), I think it should complain, but I understand that it's
not really practical now.
I don't think any existing methods do this; I'm really just
speculating about whether or not it would make sense to write a method
that way. I think it would, at an abstract level, but having the
method intervene if one calls it ambiguously also makes sense, perhaps
more sense at the practical level.
Hmm, it'd be interesting to see.