[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

to_s, inspect, etc.

Its Me

11/29/2004 11:50:00 PM

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.

Thanks!
15 Answers

Florian Gross

11/30/2004 1:08:00 AM

0

itsme213 wrote:

> 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.

Giulio Piancastelli

11/30/2004 12:29:00 PM

0

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?

Regards,
Giulio Piancastelli.

gabriele renzi

11/30/2004 12:48:00 PM

0

Giulio Piancastelli ha scritto:
> 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?
>
> Regards,
> Giulio Piancastelli.
>

Giulio Piancastelli

11/30/2004 1:01:00 PM

0

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?

Regards,
Giulio Piancastelli.

dblack

11/30/2004 1:09:00 PM

0

Charles Mills

11/30/2004 5:07:00 PM

0

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.
>
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...
-Charlie

T. Onoma

12/1/2004 4:16:00 AM

0

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...

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.

Charles Mills

12/1/2004 3:48:00 PM

0

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.
>

like:
my_instance.inspect #=> "MyClass.new(10,11,12,'ducks')"

not sure if I like that ;)

-Charlie

Hal E. Fulton

12/1/2004 3:53:00 PM

0

Charles Mills wrote:
> 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.
>>
>
> like:
> my_instance.inspect #=> "MyClass.new(10,11,12,'ducks')"
>
> not sure if I like that ;)

It's an interesting idea, but I wouldn't favor using #inspect
for that.


Hal

Hugh Sasse

12/1/2004 5:00:00 PM

0