Nathaniel Talbott
9/9/2003 2:31:00 AM
Jim Weirich [mailto:jim@mail.one.net] wrote:
> I'm not sure an extensible %_{} syntax will solve the basic problem.
> Suppose my library defines JimData to be %j{jim data goes
> here} and John wrote a library where %j{john data goes here}.
> Since defining %j{} seems to be a global decision, we would
> have two libraries that couldn't /ever/ be used in the same
> Ruby program. We have nice modules to keep our name spaces
> clean, and then we start using a name space with only 62
> possibilities (I'm counting upper/lower case letters and digits).
>
> I think an extensible %_{} syntax could only fly if we were
> able to say "Over /this/ section of code, %j will mean
> JimData, and on /that/ section of code %j will mean JohnData.
> In other words, %_{} needs scoping rules. And I'm not
> convinced the value added by extensible %_{} is more than the
> added complexity.
>
> I suspect its easier to just say JimData.new %{...}.
I was thinking about this, and wondered about doing something like:
module Kernel
def %yaml(string)
...
end
end
I.e. define the % behavior in terms of methods. This would deal nicely with
the scoping issue (JimData could have a module that defined %j, allowing
interested classes to mix it in). It would also have the benefit of allowing
the overriding of the current % operators (for all the reasons you'd want to
do that) if they were implemented in this manner.
I profess to not understanding what kind of syntactical magic is done by %q
and friends, so perhaps this isn't even feasible. I propose it, though,
because I like the idea of extensible % notation, but I don't like the idea
of adding handlers for the behavior via a global method (like
set_trace_func).
My $0.02,
Nathaniel
<:((><