require ‘pp’
s=‘abc’
t=‘#{a}’
print s.pretty_inspect
print t.pretty_inspect
this outputs:
“abc”
“#{a}”
This is of course correct - both show the content of the strings,
and both print it in a way that this can be used in an eval to get
the original string back:
eval(‘t1=’+t.pretty_inspect.chomp) # ==> t1==t
My main objection is that from a viewpoint of readability, it would
be better if pretty_inspect would generate single quoted strings
instead of double quoted ones, since less -escaping is necessary
in this case.
Since changing the present implementation of pretty_inspect might
break existing code, I suggest that
-
either pretty_inspect takes an additional argument which
tells what type of string quotation shall be used for producing
the output string in the case of pretty-printing strings, or
-
provide an additional function in pp (say: pretty_inspectq),
which formats strings by using single quotes.
The first variant would be more flexible (as we could then
even require ‘abc’.pretty_inspect(‘%q()’), producing %q(abc)
in return), but causes more work. For the second variant,
the current code of pretty_inspect can be reused, changing
just the part which formats strings. Here is an implementation
suggestion for pretty_inspectq-ing a string s:
“'”+s.gsub(/([^\]|^)‘/,’\1\\‘+"’“)+”'"
Any opinions on this?
Ronald
Ronald F. [email protected]
Phone: +49-89-452133-162
2007/8/7, Ronald F. [email protected]:
This is of course correct - both show the content of the strings,
Since changing the present implementation of pretty_inspect might
even require ‘abc’.pretty_inspect(‘%q()’), producing %q(abc)
in return), but causes more work. For the second variant,
the current code of pretty_inspect can be reused, changing
just the part which formats strings. Here is an implementation
suggestion for pretty_inspectq-ing a string s:
“'”+s.gsub(/([^\]|^)‘/,’\1\\‘+"’“)+”'"
Any opinions on this?
You would have to also explain how embedded control characters will be
printed because there is no way I know of at the moment that would
allow to embed e.g. a newline in a single quote string:
irb(main):006:0> “\n”
=> “\n”
irb(main):007:0> ‘\n’
=> “\n”
irb(main):009:0> “\064”
=> “4”
irb(main):010:0> ‘\064’
=> “\064”
If you introduce a new syntax then the output of pp becomes
inconsistent with what Ruby normally understands to be single quoted
strings. I believe you would have to have better reasons than
readability to introduce this inconsistency and make pp’s output less
useful in terms of reuse (copy and paste). Personally I doubt it is
worthwhile.
Btw, there is another variant for switching between single and double
quotes: you can use a global variable. This has the advantage that
you do not need to touch any #inspect implementation of custom classes
- but comes at a price of course.
Kind regards
robert
You would have to also explain how embedded control characters will be
printed because there is no way I know of at the moment that would
allow to embed e.g. a newline in a single quote string:
Good point. I overlooked this. But there are easy workarounds. For
example,
pretty_inspectq could revert to double quotation if the string to be
printed
can not be formatted using single quotes. Or (remember that I don’t want
to change the default behaviour of pretty_inspect) an exception is
thrown in
this case, which makes sense: The user requests pretty_inspecting in
single
quotes, but if it is not possible, we should blame the user.
If you introduce a new syntax
Certainly not! I don’t want to open that can of worms.
Btw, there is another variant for switching between single and double
quotes: you can use a global variable. This has the advantage that
you do not need to touch any #inspect implementation of custom classes
- but comes at a price of course.
Hmmmmm… here I don’t see the point.
In my case, I use pretty_inspect to “marshal” Ruby data types (they
are written to a file, which is then edited by the user, and finally
eval’ed by another Ruby application). I use pretty_inspect to easily
format Ruby structures (arrays…), but for the user, it is more
convenient
to use single quoted strings when editing the data, because he needs
to care less about escaping rules.
Ronald
2007/8/7, Ronald F. [email protected]:
thrown in
you do not need to touch any #inspect implementation of custom classes
- but comes at a price of course.
Hmmmmm… here I don’t see the point.
Global variables are generally considered bad OO and you should
normally try to avoid them if possible.
In my case, I use pretty_inspect to “marshal” Ruby data types (they
are written to a file, which is then edited by the user, and finally
eval’ed by another Ruby application). I use pretty_inspect to easily
format Ruby structures (arrays…), but for the user, it is more
convenient
to use single quoted strings when editing the data, because he needs
to care less about escaping rules.
The proper way to do this would of course be a decent parser because
eval has serious security implications. 
You could use YAML or XML
for this although I believe you will find XML too verbose.
Kind regards
robert
Here’s what I suggest:
class String
def quote(str="’")
“#{str}#{self}#{str}”
end
def quote!(str="’")
self.insert(0, str) << str
end
end
#Tests
test = “abc” => “abc”
test.quote => “‘abc’”
test.quote(""") => ““abc””
test.quote(“123”) => “123abc123”
test => “abc”
test.quote! => “‘abc’”
test => “‘abc’”
2007/8/7, Ronald F. [email protected]:
Global variables are generally considered bad OO and you should
normally try to avoid them if possible.
You got me wrong here: I wanted to say that I don’t see how globals
would help me here.
The global would be the flag which quoting style to use. Advantage is
that you do not need to pass it around (i.e. if YourClass#inspect has
some String members whose #inspect output it includes in its own
output).
Yes, security implications for instance. The user could arbitrarily ruin
anything by inserting suitable statements. Only that in this case,
security is a non-issue, but time to invest in the implementation is
one. If I define the file format as “Ruby code”, parsing is trivial,
as it is done by Ruby; and creating the file is also trivial, using
pretty_inspect.
Just wanted to make sure you are aware of the implications. If it’s
not an issue, good.
Cheers
robert
You got me wrong here: I wanted to say that I don’t see how globals
would help me here.
The global would be the flag which quoting style to use. Advantage is
that you do not need to pass it around (i.e. if YourClass#inspect has
some String members whose #inspect output it includes in its own
output).
Ah, I see. No, this would definitely be a terrible hack which we should
avoid!
After all this feedback, I think the best solution would be to start
with
one of my originally proposed solutions (either a new function, or
having
pretty_inspect accepting a parameter), and either throwing an exception
or
returning nil if the conversion can’t be done.
Ronald
Global variables are generally considered bad OO and you should
normally try to avoid them if possible.
You got me wrong here: I wanted to say that I don’t see how globals
would help me here.
In my case, I use pretty_inspect to “marshal” Ruby data types (they
are written to a file, which is then edited by the user, and finally
eval’ed by another Ruby application). I use pretty_inspect to easily
format Ruby structures (arrays…), but for the user, it is more
convenient
to use single quoted strings when editing the data, because he needs
to care less about escaping rules.
The proper way to do this would of course be a decent parser because
eval has serious security implications.
Yes, security implications for instance. The user could arbitrarily ruin
anything by inserting suitable statements. Only that in this case,
security is a non-issue, but time to invest in the implementation is
one. If I define the file format as “Ruby code”, parsing is trivial,
as it is done by Ruby; and creating the file is also trivial, using
pretty_inspect.
Ronald