I was thinking that something similar to caller() but with binding data instead of position strings. But this proposal is interesting too, although I don't prefer much the caret (^).
Let me consider.
-- matz.
Zallus: "Why not another one?" (punctuation character used for semantics) -- do you mean that you think Ruby is already so cluttered that it doesn't matter? I disagree; I think Ruby is still very clean-looking. I also think it can't afford things like this, without giving up that clean look.
Matz: please don't add more punctuation.... Even slightly longer code is better than everything being compressed into punctuation.
(Sorry to be negative, but it worries me.)
-- David Black
Matz, I would prefer something like caller() over this. Even better, why not promote the results of caller() to a full class, i.e.:
class Caller
attr_reader :name # The caller's "name"
attr_reader :file # The caller's "filename"
attr_reader :line # The caller's "line number"
attr_reader :binding # The caller's binding
... # as appropriate
end
-- Austin Ziegler
What ever happened to [accepted] RCR#29? I think that would provide the feature that this RCR really wants, plus more.
-- Paul Brannan
What was RCR#29? I agree that a caller_binding would be better. Punctuation is ugly,imo, and not self explanatory.
You could just add an argument to binding() which defaults to zero if not supplied. Zero would mean the current context with higher numbers returning the corresponding caller's context.
-- George Bennett
Another possibility:
def xyz( &caller = self ) xxx end
When xyz is called without a block parameter, instead of using "self" as a default value, the interpretor would use the binding of the caller (or, better, when available, the caller proc object or else a Method object).
OTOH if feel like binding( 1) is cleaner.
-- JeanHuguesRobert
I strongly agree with Austin's suggestion, where "caller" returns an array of Caller objects. That seems more useful than the current behaviour and a good way to get the calling method's binding, too, which I'm most keen on (see ruby-talk:103293). I have to vote against this specific RCR though, because the proposed mechanism does not seem a good fit with Ruby. -- Gavin Sinclair
I was thinking that something similar to caller() but with binding data instead of position strings. But this proposal is interesting too, although I don't prefer much the caret (^).
Let me consider.
-- matz.
Zallus: "Why not another one?" (punctuation character used for semantics) -- do you mean that you think Ruby is already so cluttered that it doesn't matter? I disagree; I think Ruby is still very clean-looking. I also think it can't afford things like this, without giving up that clean look.
Matz: please don't add more punctuation.... Even slightly longer code is better than everything being compressed into punctuation.
(Sorry to be negative, but it worries me.)
-- David Black
Matz, I would prefer something like caller() over this. Even better, why not promote the results of caller() to a full class, i.e.:
-- Austin Ziegler
What ever happened to [accepted] RCR#29? I think that would provide the feature that this RCR really wants, plus more.
-- Paul Brannan
What was RCR#29? I agree that a caller_binding would be better. Punctuation is ugly,imo, and not self explanatory.
You could just add an argument to binding() which defaults to zero if not supplied. Zero would mean the current context with higher numbers returning the corresponding caller's context.
-- George Bennett
Another possibility:
def xyz( &caller = self ) xxx end
When xyz is called without a block parameter, instead of using "self" as a default value, the interpretor would use the binding of the caller (or, better, when available, the caller proc object or else a Method object).
OTOH if feel like binding( 1) is cleaner.
-- JeanHuguesRobert
I strongly agree with Austin's suggestion, where "caller" returns an array of Caller objects. That seems more useful than the current behaviour and a good way to get the calling method's binding, too, which I'm most keen on (see ruby-talk:103293). I have to vote against this specific RCR though, because the proposed mechanism does not seem a good fit with Ruby. -- Gavin Sinclair