From: Nathaniel Talbott <nathaniel@...>
Date: 2003-09-09T11:31:27+09:00
Subject: Re: YAML Patch

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

<:((><