[ruby-core:45702] Re: [RFC] RubyVM::FrameInfo.caller method

On 18 June 2012 09:25, SASADA Koichi <[e-mail]> wrote:
> Hi,
>
> (2012/06/17 3:20), Benoit Daloze wrote:
>> It is indeed a very interesting feature, parsing caller is very
>> fragile in nature and not very portable.
>>
>> Do you intend this to be ported to other implementations? From the
>> user POV, that would be very valuable.
>
> POV?

"Point of view", sorry for using an abbreviation, I should have
written it entirely.

>> Is RubyVM::Backtrace::Location appropriate for other impls too?
>> Or do you think it does not matter what class it is, only it has the
>> set or a subset of the methods you describe?
>
> Good point.  want to discuss about it.
>
> I have two reasons.
>
> (1)
> I assume nobody uses RubyVM::Backtrace and RubyVM::Backtrace::Location
> class names because users only use caller_locations() Kernel methods.

I think so as well.

> (2)
> "Backtrace" and "Locatin" are common name. 'm afraid that someone make
> their class named "Backtrace" and "Location". here are no possibility
> to conflict such names under ::RubyVM.
>
> I welcome the good naming.

Indeed, a top-level constant might be conflict-prone.
I'm actually wondering if you think RubyVM is supposed to be
MRI-specific or if it might be anything related to a Ruby VM.
Having the exact same class name does not seem essential, but I think
it would be better for consistency (and
specification/documentation/etc).

>> Just wondering, would it be easy to access the Binding of the nth
>> caller? That's an evil feature, and it must be lazy or optional for
>> performance I guess, but it's always fun to play with.
>
> I agree that it is funny and powerful tool.
>
> But I'm not sure it is good idea for Ruby. or example, people want to
> make more magical codes. nd it prevent optimizations.
>
> I'll provide such feature for *debugger*, as more restricted/implemented
> depend (non-standard) fashion.

You're right, it's not a good idea for that to be accessible in general.

(But having that accessible from Ruby would allow to write a very
simple debugger entirely in Ruby that would be way better than #p)