Where would I find a nice summary of to_s, inspect, p, etc. and the core
ones to override for various purposes?
Are to_s, inspect, etc. defined more-or-less consistently for the library
classes? Are they used consistently by the various tools like irb, debug,
test/unit, breakpoint, etc?
I often find myself with quite unhelpful presentations of objects e.g. when
a test/unit assertion fails, I might get a 2-page long description of one of
the objects involved. For my own classes I poke around at to_s and friends
but it often feels like guesswork.
Where would I find a nice summary of to_s, inspect, p, etc. and the core
ones to override for various purposes?
I think ri would help, but I will summarize this below.
Are to_s, inspect, etc. defined more-or-less consistently for the library
classes? Are they used consistently by the various tools like irb, debug,
test/unit, breakpoint, etc?
..inspect is usually used for debug purposes and .to_s for end-user purposes. p obj is the same as puts obj.inspect. irb and breakpoint both use .inspect -- I am not sure about test/unit but would it expect it to also use it.
I often find myself with quite unhelpful presentations of objects e.g. when
a test/unit assertion fails, I might get a 2-page long description of one of
the objects involved. For my own classes I poke around at to_s and friends
but it often feels like guesswork.
prettyprint.rb helps in that case -- it wraps and indents the structure of the Object. There's also an extension that provides pp_s which is to pp as inspect is to p.
It sounds from the discussion that we could benefit from a well thought out
(and/or well described!) framework for a set of print-related methods. I
know consistent use of these would help _me_ a lot.
A naive (and incomplete and incorrect) example. Any resemblance to real Ruby
methods is purely accidental.
- #short: a context-insensitive short string (no newlines) identifying the
object + class
- #probe: 1-level deep object structure + #short descriptions of 2nd level,
single line
- #probe n: N-level deep object structure
- #probe n Filter: N-level deep object structure only showing elements of
Filter
- #inspect: show full recursive object structure, ending at [String, Symbol,
Int, ...]
- #identify should show short string for object identification e.g. just a
'name' attribute
- Object#short by default will print class name + #to_s
- #to_s should ....
- Object#inspect by default will ....
Coming up with such a framework will take someone smarter than I.
"itsme213" <itsme213@hotmail.com> wrote in message
news:8BOqd.59658$g21.3667@fe1.texas.rr.com...
Where would I find a nice summary of to_s, inspect, p, etc. and the core
ones to override for various purposes?
Are to_s, inspect, etc. defined more-or-less consistently for the library
classes? Are they used consistently by the various tools like irb, debug,
test/unit, breakpoint, etc?
I often find myself with quite unhelpful presentations of objects e.g.
when
a test/unit assertion fails, I might get a 2-page long description of one
of
···
the objects involved. For my own classes I poke around at to_s and friends
but it often feels like guesswork.
itsme213 wrote:
> Are to_s, inspect, etc. defined more-or-less consistently for the
library
> classes? Are they used consistently by the various tools like irb,
debug,
> test/unit, breakpoint, etc?
.inspect is usually used for debug purposes and .to_s for end-user
purposes.
So, why does [1,2,3].to_s give '123' and [1,2,3].inspect give '[1, 2,
3]' as answers? Not a really end-user answer, the one given by
Array#to_s, isn't it? The inspect method here is much more end-user
oriented: why is that?
itsme213 wrote:
> Are to_s, inspect, etc. defined more-or-less consistently for the
library
> classes? Are they used consistently by the various tools like irb,
debug,
> test/unit, breakpoint, etc?
.inspect is usually used for debug purposes and .to_s for end-user
purposes.
So, why does [1,2,3].to_s give '123' and [1,2,3].inspect give '[1, 2,
3]' as answers? Not a really end-user answer, the one given by
Array#to_s, isn't it? The inspect method here is much more end-user
oriented: why is that?
that allows you to drill as deep into the object as you want. For debugging of
complex structures it might be quite helpfull.
(Beware of its alpha status)
Regards,
Brian
···
On Thu, 2 Dec 2004 05:27:44 +0900 "itsme213" <itsme213@hotmail.com> wrote:
It sounds from the discussion that we could benefit from a well thought out
(and/or well described!) framework for a set of print-related methods. I
know consistent use of these would help _me_ a lot.
A naive (and incomplete and incorrect) example. Any resemblance to real Ruby
methods is purely accidental.
- #short: a context-insensitive short string (no newlines) identifying the
object + class
- #probe: 1-level deep object structure + #short descriptions of 2nd level,
single line
- #probe n: N-level deep object structure
- #probe n Filter: N-level deep object structure only showing elements of
Filter
- #inspect: show full recursive object structure, ending at [String, Symbol,
Int, ...]
- #identify should show short string for object identification e.g. just a
'name' attribute
- Object#short by default will print class name + #to_s
- #to_s should ....
- Object#inspect by default will ....
Coming up with such a framework will take someone smarter than I.
It sounds from the discussion that we could benefit from a well thought out
(and/or well described!) framework for a set of print-related methods. I
know consistent use of these would help _me_ a lot.
A naive (and incomplete and incorrect) example. Any resemblance to real Ruby
methods is purely accidental.
- #short: a context-insensitive short string (no newlines) identifying the
object + class
what about just using to_s
"#<Class:ID>>1>"
- #probe: 1-level deep object structure + #short descriptions of 2nd level,
single line
- #probe n: N-level deep object structure
- #probe n Filter: N-level deep object structure only showing elements of
Filter
These could be useful for some sort of graphing package (showing object graphs) / object browser.
- #inspect: show full recursive object structure, ending at [String, Symbol,
Int, ...]
- #identify should show short string for object identification e.g. just a
'name' attribute
- Object#short by default will print class name + #to_s
- #to_s should ....
- Object#inspect by default will ....
I think the current framework (#to_s and #inspect) does the job... seems like this would create extra work for developers and muck up the name space. It is probably enough to just override Object#inspect in really complicated classes (if someone else is going to be using them).
Are to_s, inspect, etc. defined more-or-less consistently for the
library
classes? Are they used consistently by the various tools like irb,
debug,
test/unit, breakpoint, etc?
.inspect is usually used for debug purposes and .to_s for end-user
purposes.
So, why does [1,2,3].to_s give '123' and [1,2,3].inspect give '[1, 2,
3]' as answers? Not a really end-user answer, the one given by
Array#to_s, isn't it? The inspect method here is much more end-user
oriented: why is that?
> itsme213 wrote:
> > Are to_s, inspect, etc. defined more-or-less consistently for the
library
> > classes? Are they used consistently by the various tools like irb,
debug,
> > test/unit, breakpoint, etc?
>
> .inspect is usually used for debug purposes and .to_s for end-user
> purposes.
So, why does [1,2,3].to_s give '123' and [1,2,3].inspect give '[1, 2,
3]' as answers? Not a really end-user answer, the one given by
Array#to_s, isn't it? The inspect method here is much more end-user
oriented: why is that?
I think it's probably because the '123' form is conceivably useful
once in a while as a string, whereas '[1,2,3]' probably isn't. Also, #inspect sort of has to return something other than '123', so having #to_s also return that would just duplicate that functionality.
Array#to_s is essentially Array#join with no args... irb uses #inspect to display the result of each statement. It is a bit annoying when you have highly nested objects and/or objects with lots of instance variables that give you about a page and a half of output when inspect is called. I guess if you know your class is going to be like that is may be useful to define inspect something like the following:
···
On Nov 30, 2004, at 5:08 AM, David A. Black wrote:
Hi --
On Tue, 30 Nov 2004, Giulio Piancastelli wrote:
Florian Gross wrote:
itsme213 wrote:
Are to_s, inspect, etc. defined more-or-less consistently for the
library
classes? Are they used consistently by the various tools like irb,
debug,
test/unit, breakpoint, etc?
.inspect is usually used for debug purposes and .to_s for end-user
purposes.
So, why does [1,2,3].to_s give '123' and [1,2,3].inspect give '[1, 2,
3]' as answers? Not a really end-user answer, the one given by
Array#to_s, isn't it? The inspect method here is much more end-user
oriented: why is that?
I think it's probably because the '123' form is conceivably useful
once in a while as a string, whereas '[1,2,3]' probably isn't. Also, #inspect sort of has to return something other than '123', so having #to_s also return that would just duplicate that functionality.
###
def inspect()
"#<#{self.class}: #{@very_important_ivar}>"
end
###
Opinions may differ though...
-Charlie
Indeed. I like the idea that #inspect produce a string that will produce an
equivalent object when passed through #eval. This already works for literal
forms like Array.
T.
···
On Tuesday 30 November 2004 12:07 pm, Charles Mills wrote:
Array#to_s is essentially Array#join with no args... irb uses #inspect
to display the result of each statement. It is a bit annoying when you
have highly nested objects and/or objects with lots of instance
variables that give you about a page and a half of output when inspect
is called. I guess if you know your class is going to be like that is
may be useful to define inspect something like the following:
###
def inspect()
"#<#{self.class}: #{@very_important_ivar}>"
end
###
Opinions may differ though...
On Nov 30, 2004, at 8:15 PM, trans. (T. Onoma) wrote:
On Tuesday 30 November 2004 12:07 pm, Charles Mills wrote:
> may be useful to define inspect something like the following:
> ###
> def inspect()
> "#<#{self.class}: #{@very_important_ivar}>"
> end
> ###
> Opinions may differ though...
Indeed. I like the idea that #inspect produce a string that will produce an
equivalent object when passed through #eval. This already works for literal
forms like Array.
On Nov 30, 2004, at 8:15 PM, trans. (T. Onoma) wrote:
On Tuesday 30 November 2004 12:07 pm, Charles Mills wrote:
> may be useful to define inspect something like the following:
> ###
> def inspect()
> "#<#{self.class}: #{@very_important_ivar}>"
> end
> ###
> Opinions may differ though...
Indeed. I like the idea that #inspect produce a string that will produce an
equivalent object when passed through #eval. This already works for literal
forms like Array.
Indeed. I like the idea that #inspect produce a string that will produce an
equivalent object when passed through #eval. This already works for literal
forms like Array.
It's an interesting idea, but I wouldn't favor using #inspect
for that.
I'd like something like this. It would mean one could marshal data
in a readable form, and not have the Pythonesque whitespace issues
that YAML brings.
YAML is very good for many things, but if other people (whose
background is unknown) need to edit the data, you can bet one of
them will not notice the whitespace subtleties, and break something.
I'd like something with the conciseness of ruby or YAML, but with a
more robust format.
I don't see how one could create self-referential structures this
way though, or have an array with more than one occurrance of
exactly the same object. I don't want to ask for pointers in Ruby!
Hal
Hugh
···
On Thu, 2 Dec 2004, Hal Fulton wrote:
On Nov 30, 2004, at 8:15 PM, trans. (T. Onoma) wrote:
On Nov 30, 2004, at 8:15 PM, trans. (T. Onoma) wrote:
Indeed. I like the idea that #inspect produce a string that will produce an
equivalent object when passed through #eval. This already works for literal
forms like Array.
It's an interesting idea, but I wouldn't favor using #inspect
for that.
I'd like something like this. It would mean one could marshal data
in a readable form, and not have the Pythonesque whitespace issues
that YAML brings.
YAML is very good for many things, but if other people (whose
background is unknown) need to edit the data, you can bet one of
them will not notice the whitespace subtleties, and break something.
I'd like something with the conciseness of ruby or YAML, but with a
more robust format.
I don't see how one could create self-referential structures this
way though, or have an array with more than one occurrance of
exactly the same object. I don't want to ask for pointers in Ruby!
You don't need pointers. Just use variables.
Check out amarshal on RAA. It handles references, but it's not as pretty as hand-written ruby code.
On Nov 30, 2004, at 8:15 PM, trans. (T. Onoma) wrote:
Indeed. I like the idea that #inspect produce a string that will produce an
equivalent object when passed through #eval. This already works for literal
forms like Array.
