However, that is not what inspect returns for that object. It would be
really helpful to me if I could tell Ruby to call inspect like it normally
does, rather than just telling me what class it’s in.
In my particular situation, I am using Modules all over the place instead of
classes. (It makes sense in this particular context.) `foo’ might need to
be defined in one of the modules (but I don’t know which one because the
real inspect wasn’t called), or this might be the wrong kind of object,
signifying a bug elsewhere (but I don’t know what kind of object this is,
since the real inspect wasn’t called).
However, that is not what inspect returns for that object. It would be
really helpful to me if I could tell Ruby to call inspect like it normally
does, rather than just telling me what class it’s in.
Yeah, right. It’s been like that from the beginning, but I don’t
remember why I did so. OK, I will change to use “inspect” and see how
it work.
However, that is not what inspect returns for that object. It would be
really helpful to me if I could tell Ruby to call inspect like it normally
does, rather than just telling me what class it’s in.
Yeah, right. It’s been like that from the beginning, but I don’t
remember why I did so. OK, I will change to use “inspect” and see how
it work.
If the object doesn’t have “inspect”, it will cause infinite
recursion. Isn’t this the reason?
A thread some time ago discussed the creation of absolutely plain
objects with no methods or anything defined. I don’t know if anyone
is still interested in that but it would be a shame if an error failed
to print while they were experimenting.
Gavin
···
On Monday, March 31, 2003, 2:30:09 PM, Yukihiro wrote:
In message “Re: inspect question/request” on 03/03/31, Gavin Sinclair gsinclair@soyabean.com.au writes:
Who wants to undef “inspect”?
A thread some time ago discussed the creation of absolutely plain
objects with no methods or anything defined. I don’t know if anyone
is still interested in that but it would be a shame if an error failed
to print while they were experimenting.
If something, no matter how stupid, is possible, then someone, somewhere
will do it.
Perhaps in the absence of an inspect method (for whatever reason), a
fall-back to the original behavior is in order?
I know. I did it once, and asked myself how often it occurs, and how
much it cost to cover it, then removed fall back code. Was I wrong?
matz.
I doubt that the test would affect the performance of correct code if
it’s performed in the error-handling routine (unless there’s an obscure
implemetation detail that I’m overlooking :-), and it seems to me that
being able to “fail correctly” is important in a language that allows
graceful recovery from exceptions.
If, on the other hand, there were an actual performance hit for non-buggy code (i.e., code that doesn’t call non-existent methods very
often), then that would be another matter entirely.
···
In message “Re: inspect question/request” > on 03/03/31, Julian Snitow vangczung@yahoo.com writes:
