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

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?

> 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.  I 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.

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

I welcome the good naming.


>> Other guy pointed out that FrameInfo is to noisy (FooInfo is bad naming
>> rule).  At last, we change the class name FrameInfo to Location.
>>
>>>       * vm_backtrace.c: change names.
>>>         (1) Class name: RubyVM::FrameInfo -> RubyVM::Backtrace::Location.
>>>         (2) Method name: RubyVM::FrameInfo.caller ->
>>>             Kernel.caller_locations.
>>>         (3) Instance methods of
>>>               RubyVM::FrameInfo (RubyVM::Backtrace::Location)
>>>             (3-1) name -> label
>>>             (3-2) basename -> base_label (basename is confusing with
>>>                   File.basename)
>>>             (3-3) line_no -> lineno (We have already similar name
>>>                   File#lineno, commented by kou [ruby-dev:45686]).
>>>             (3-4) filename -> path.
>>>             (3-5) filepath -> absolute_path.
>>>             (3-5) iseq -> removed (we will make other APIs to access iseq
>>>                   and other information of frame for debugging).
>>
>> What do you think about it?
> 
> Sounds good to me.
> 
> 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.  For example, people want to
make more magical codes.  And it prevent optimizations.

I'll provide such feature for *debugger*, as more restricted/implemented
depend (non-standard) fashion.

-- 
// SASADA Koichi at atdot dot net