[ruby-core:35046] Re: [Ruby 1.9-Bug#4352] [patch] Fix eval(s, b) backtrace; make eval(s, b) consistent with eval(s)

On Wed, Feb 2, 2011 at 10:47 AM, Yusuke ENDOH <[e-mail]> wrote:

> Hi,
>
> 2011/2/2 James M. Lawrence <[e-mail]>:
> > Thank you for that detailed explanation. The problem for me is the
> > connection to source_location, which should be usable by tools.
>
> What kind of tools are you talking about?
> Even if a binding location is discarded, we can still fake __FILE__
> and __LINE__ without using a binding:
>
>  eval <<-END, nil, "/etc/passwd", 1
>    def foo
>    end
>  END
>  p method(:foo).source_location  #=> ["/etc/passwd", 1]
>
> So, source_location user should know and accept the fact that the
> information is not trustable.
>

Sigh. The main use of setting the file and line in an eval() call is to get
around the fact that the location is not what folks expect.

In fact, that's why you yourself used that form to suggest how to rewrite
the code to do what James M. Lawrence seems to want.

See also
http://ola-bini.blogspot.com/2008/01/ruby-antipattern-using-eval-without.html.
It is called an "anti-pattern" there which I guess is used in a derogatory
fashion.

A place where setting the file and line is used is in template systems like
merb or erb  where the file the user works on is not a Ruby file but a
template file that expands to a Ruby file. In that situation, disregarding
the expanded Ruby file is convenient since there can only be one location
attached in the Ruby implementation.

However I don't see why a templating system couldn't also provide an
expanded Ruby file for debugging problems much as one can get the
C-preprocessed output for a C program when one wants.

In the trepanning debuggers (http://github.com/rocky/rb-trepanning and
http://github.com/rbx-trepanning) I allow similar types of filename
remapping to go on in the debugger. But in reporting a location I always try
to report both locations; and it is done automatically in showing an eval
location.

But shouldn't we try to address the location problem head on in the Ruby
implementation? I suspect it too late to try to change Ruby MRI 1.x, but
perhaps in Ruby 2.x some thought could be given to how to address.

If the fact that source_location is not trustable is a a concern, then
perhaps setting the file and line parameters on eval can be disallowed at
some level greater than 0 and less than 4 which is where eval() is
disallowed totally.




> Why do you think only a binding location as a problem?
>
> --
> Yusuke Endoh <[e-mail]>
>
>