This looks great.  Thank you.

Yes, I see the problem with using the suffix verbatim as the method 
identifier.
I just thought it looked cleaner that way and it partitioned the method 
space nicely.

But, just think about what this does:

    "exit"__send__  #oops!

So, how about just putting a 'literal_' before the suffix when doing the 
method lookup?  This is similar to Florian's suggestion, but a little
different:

"1:10"PM calls "1:10".literal_PM

Note that literal_PM is an instance method of String.  After all,
these methods all operate on strings and there is no reason that
some other method for parsing text could not call them.

I haven't tried your patch yet.  Does it also handle:

1.10PM

Just curious.  I never really thought I'd see this implemented
so quickly.  Thanks again,

- Brent


Peter wrote:

 > There's no problem with allowing any method identifier as suffix from 
the parsing point of view.
 >
 > A possible implementation is attached. "1:10"PM calls 
String::Literal::PM("1:10"). It is implemented differently than the 
patch for number literal suffixes which shows in the fact that there can 
be a space between the string and the suffix, and that a suffix like 
'class' won't work because 'class' is a reserved word. This was the easy 
implementation...
 >
 > Funny thing: "1:10"methods calls String::Literal::methods("1:10") 
which happily returns all methods in String::Literal. That's the 
downside of using the unchanged suffix as method name.
 >
 > Peter
 >
 >
 >

-- 
  Brent Roman                                   MBARI
  Software Engineer               Tel: (831) 775-1808
  7700 Sandholdt Road,         Moss Landing, CA 95039
  mailto:brent / mbari.org  http://www.mbari.org/~brent


-- 
  Brent Roman
  Software Engineer                 Tel: 831 775 1808
  425 Clinton St., Santa Cruz,      California, 95062
  mailto:brent / mbari.org  http://www.mbari.org/~brent