%
literals. %
literals are especially useful in reducing code clutter for commonly recreated data structures. Presently, the built-in %
literals (namely %q
, %Q
, %r
, %s
, %w
and %x
) are handled opaquely by the Ruby interpreter. User-defined %
literals can be provided via %
methods in the same way as the present ``
(backquote) construct, which in itself calls %x
. Programmers would then be able to swiftly create data structures particular to their needs. For example, %y
could be used for YAML::load
.
%
literals conforms to the same rules as the current literals, i.e., matching braces, etc. Additionally, the literal's closing delimiter may be followed by any number of letters, serving as a limited form of parameter, congruent with the present behavior of %r
.
%
literal is evaluated (i.e. %m
, where m is any lowercase letter), the literal and its parameters are passed as strings to a method of like name, e.g. def %m(string, options)
. This method then interprets the string according to any optional parameters and returns a representative object. In the case of an uppercase %
literal (%M
, where M is an uppercase letter) the lowercase method is also called, but only after the interpreter applies the additional substitutions for double-quoted strings.
%
method, we will first give the trivial case of %q:
module Kernel def %q(string) string end end
class OurClass private def %q(string, params) params.split(//).each do |p| case p when 'u' string.upcase! else raise "unknown string option: #{p}" end end string end end
OurClass#%q
as the method to call. An example would be:
class OurClass def test %q{Hello #{world}!}u end end
u
is passed in the same way as to the %r
literal in Ruby now. When calling OurClass#test
, the evaluation of the literal will result in a call to OurClass#%q
with 'Hello #{world}!' and 'u' as parameters. This method will then return 'HELLO #{WORLD}!'
class OurClass def test world = 'ruby-talk' %Q{Hello #{world}!}u end end
OurClass#test
will again result in a call to OurClass#%q
, but this time with 'Hello ruby-talk!' and 'u' as parameters. This is because the uppercase variant does do string interpolation. The result of it all would be 'HELLO RUBY-TALK!'.
%
literal method can return an object other than a string. For instance, this is how the aforementioned YAML case is defined:
module Kernel def %y(string, params) YAML::load(string) end end
%r
:
module Kernel def %r(string, options) Regexp.new(string, options.split(//).inject(0) { |v, c| v | Hash.new { |h, k| raise "unknown regexp option - #{k}" }.update({"i" => Regexp::IGNORECASE, "m" => Regexp::MULTILINE, "x" => Regexp::EXTENDED}[c]}) end end
%
literals. So it would also be possible to allow more than one letter after the %
, e.g., %yaml
which is less cryptic than %y
(although longer). While not a necessity, it increases the possibilities.
%
literals without changing the Ruby interpreter. Requests for new %
literals have come up a few times on ruby-talk, e.g., , , ; lots of people would know what to do with this feature: YAML literals, XML literals, syntax literals (on-the-fly parser generation), ...%
literals have: convenience, with less typing for commonly occurring data structures, conciseness, thus reducing code clutter and less escaping of quotes in literals.%
literals and the ``
notation.%
literals must be handled with care. When using other's people's libraries, it may cause non-backward compatiblity issues. Then again, this comes with the territory of having open classes. While overriding the built-in %
literals could be prohibited, a warning would probably suffice.%r
and %x
, though both lowercase, are presently treated as double-quoted, thus differing from the general convention set forth in this proposal. Changing this can break backward compatibility. In which case a phased implementation is recommended, issuing a strong warning for a number of release cycles. The (less elegant) alternative is to make asymmetric exceptions for %r
and %x
regardless of whether they are overridden or not. These two will then always be parsed as if double-quoted, rendering the uppercase variants useless.%
literal syntax to allow any letter and allow any parameters to each literal. Again this strictly extends ruby's syntax and does not clash with Ruby's syntax.%
literals. During the parsing phase, the literal and its flags are stored as strings, the method that will be called at evaluation is stored in some form and it is flagged as being single or double-quoted. At evaluation time all required substitutions are performed before passing the literal and its parameters as strings on to the according method. The result of that method is the result of the evaluation of the literal.Back to RCRchive.
RCR Submission page and RCRchive powered by Ruby, Apache, RuWiki (modified), and RubLog