TrueClass responds to “clone” but when you call it, the method just throws an
error that says “can’t clone TrueClass.” How can I tell when an objects
support a given method if they implement them but then raise exceptions? Is
there some other methodology I should use?
Sean O'DellSean O’Dell wrote:
TrueClass responds to “clone” but when you call it, the method just throws an
error that says “can’t clone TrueClass.” How can I tell when an objects
support a given method if they implement them but then raise exceptions? Is
there some other methodology I should use?
Interesting question. I suppose you could always catch the exception
and then set your own flag that says you can’t clone.
This raises the question in my mind of whether the clone method should
simply be removed from such classes.
Hal
Hello Sean,
TrueClass responds to "clone" but when you call it, the method just throws an
error that says "can't clone TrueClass." How can I tell when an objects
support a given method if they implement them but then raise exceptions? Is
there some other methodology I should use?
Can someone tell me why we can't clone "expanded" objects like
booleans, integers, ... ? Wouldn't it be better to simply return the
"same" boolean, integer, ... ?
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
For example, the classes in socket have plenty of methods which raise an
error on some platforms. I would also preferred them not to be defined
at all.
If you don’t test the existence of the method before calling it, you
will get an exception just as well. So I don’t see the point in
unimplemented exception raising methods.
Guillaume.
On Thu, 2004-05-27 at 17:24, Hal Fulton wrote:
This raises the question in my mind of whether the clone method should
simply be removed from such classes.
Sean O’Dell wrote:
TrueClass responds to “clone” but when you call it, the method just
throws an error that says “can’t clone TrueClass.” How can I tell when
an objects support a given method if they implement them but then raise
exceptions? Is there some other methodology I should use?Interesting question. I suppose you could always catch the exception
and then set your own flag that says you can’t clone.
That sort of makes respond_to? less functional than advertised.
This raises the question in my mind of whether the clone method should
simply be removed from such classes.
My feeling is, it should be removed. I would think that the rule of thumb is
“if it respond_to?'s, it is implemented.”
Sean O'Dell
On Thursday 27 May 2004 14:24, Hal Fulton wrote:
There’s a slight difference between these examples, in that the Socket methods
are defined on some platform. I don’t think I would expect methods that
aren’t supported by a particular platform to be undefined, they’d just result
in errors when called. Ruby sockets should probably be abstracted above the
underlying API and you probably wouldn’t want the interface changing based
on what operating system the user has.
TrueClass#clone, however, is invalid on every platform, so I’d say it’s more
of a candidate to be undefined.
– Dan
On Thursday 27 May 2004 5:29 pm, Guillaume Marcais wrote:
For example, the classes in socket have plenty of methods which raise an
error on some platforms. I would also preferred them not to be defined
at all.If you don’t test the existence of the method before calling it, you
will get an exception just as well. So I don’t see the point in
unimplemented exception raising methods.Guillaume.
Hi –
Sean O’Dell wrote:
TrueClass responds to “clone” but when you call it, the method just
throws an error that says “can’t clone TrueClass.” How can I tell when
an objects support a given method if they implement them but then raise
exceptions? Is there some other methodology I should use?Interesting question. I suppose you could always catch the exception
and then set your own flag that says you can’t clone.That sort of makes respond_to? less functional than advertised.
It’s just being very literal.
This raises the question in my mind of whether the clone method should
simply be removed from such classes.My feeling is, it should be removed. I would think that the rule of thumb is
“if it respond_to?'s, it is implemented.”
What about NotImplementedError? 
David
On Fri, 28 May 2004, Sean O’Dell wrote:
On Thursday 27 May 2004 14:24, Hal Fulton wrote:
–
David A. Black
dblack@wobblini.net
There’s a slight difference between these examples, in that the Socket methods
are defined on some platform. I don’t think I would expect methods that
aren’t supported by a particular platform to be undefined, they’d just result
in errors when called.
But in both cases you get an error if you call the method. In one case a
NotImplementedError (or sth alike) and in the other NoMethodError. The
difference is in the second case, you can test them with #respond_to?
instead of a begin … rescue block.
Ruby sockets should probably be abstracted above the
underlying API and you probably wouldn’t want the interface changing based
on what operating system the user has.
Abstraction is probably what you would want, but you can only go so far.
Especially in the case of socket, some platform dependant methods rely
on the existence of a particular ioctl. If the system doesn’t provide
it, you will likely not be able to do anything about it.
Nothing super important though, I live very well with the way it is now.
Guillaume.
On Thu, 2004-05-27 at 17:41, Dan Doel wrote:
TrueClass#clone, however, is invalid on every platform, so I’d say it’s more
of a candidate to be undefined.
Why have respond_to? at all then? Why not just catch NotImplementedError
everywhere you need to check an object before trying to call a method?
Sean O'Dell
On Thursday 27 May 2004 15:05, David A. Black wrote:
Hi –
On Fri, 28 May 2004, Sean O’Dell wrote:
On Thursday 27 May 2004 14:24, Hal Fulton wrote:
Sean O’Dell wrote:
TrueClass responds to “clone” but when you call it, the method just
throws an error that says “can’t clone TrueClass.” How can I tell
when an objects support a given method if they implement them but
then raise exceptions? Is there some other methodology I should use?Interesting question. I suppose you could always catch the exception
and then set your own flag that says you can’t clone.That sort of makes respond_to? less functional than advertised.
It’s just being very literal.
This raises the question in my mind of whether the clone method should
simply be removed from such classes.My feeling is, it should be removed. I would think that the rule of
thumb is “if it respond_to?'s, it is implemented.”What about NotImplementedError?
Convenience?
It really can only do what it’s doing though, no? Trying to determine
anything beyond “does there exist an implementation, however crappy or
useless it may be” sounds a lot like trying to solve the halting
problem.
On Fri, 28 May 2004 07:15:59 +0900, Sean O’Dell sean@celsoft.com wrote:
Why have respond_to? at all then? Why not just catch NotImplementedError
everywhere you need to check an object before trying to call a method?
Michael Campbell wrote:
Why have respond_to? at all then? Why not just catch NotImplementedError
everywhere you need to check an object before trying to call a method?Convenience?
It really can only do what it’s doing though, no? Trying to determine
anything beyond “does there exist an implementation, however crappy or
useless it may be” sounds a lot like trying to solve the halting
problem.
It’s not really a question of how respond_to? should behave or how much
work it should do.
The question is: Do we gain anything by defining TrueClass#clone rather
than just leaving it nonexistent?
The only rationale I can think of is that “later” there might be a
TrueClass#clone implemented, and we’re leaving a placeholder for it…
but this seems unlikely to me and a flimsy justification.
Hal
On Fri, 28 May 2004 07:15:59 +0900, Sean O’Dell sean@celsoft.com wrote:
It’s not really a question of how respond_to? should behave or how much
work it should do.The question is: Do we gain anything by defining TrueClass#clone rather
than just leaving it nonexistent?
That was the reason for Sean asking, but his original question was,
“How can I tell when an objects support a given method if they
implement them but then raise exceptions? Is
there some other methodology I should use?”
To which the answer, sadly, is not “respond_to?” I think due to the
fact it just can’t do what Sean was asking, reliably enough to be
called a canonical pattern, no?
I think Sean hit on the answer himself though, with the “try it and
catch the exception” answer.
The only rationale I can think of is that “later” there might be a
TrueClass#clone implemented, and we’re leaving a placeholder for it…
but this seems unlikely to me and a flimsy justification.
Indeed.
On Fri, 28 May 2004 07:28:10 +0900, Hal Fulton hal9000@hypermetrics.com wrote: