From: David Alan Black <dblack@...>
Date: 2001-07-03T01:22:26+09:00
Subject: [ruby-talk:17159] Re: RCR: Exception methods (was: Re:  Re: keeping an Exception object alive)

On Tue, 3 Jul 2001, Dave Thomas wrote:

> David Alan Black <dblack@candle.superlink.net> writes:
>
> > With regard to the second point: it's that I think it should be a
> > private method, but that I wonder whether it should be/needs to be a
> > Ruby method at all.  It seems more like part of the implementation
> > internals (testing for validity of arguments to #raise).
> >
> > By way of comparison: every time there's:
> >
> >    if (TYPE(arg) == T_ARRAY) {...}
> >
> > there could be, instead, something like:
> >
> >    ID array = rb_intern("array");
> >    /* ... */
> >    if (rb_respond_to(arg, array)) {...}
> >
> > along with an #array method to which some objects would respond and
> > others wouldn't.  That would feel, to me, like a blurring of
> > implementation internals (testing for type) and Ruby itself... which
> > is what I'm wondering about #exception.
>
> To be fair, just about every time the interpreter now checks for a
> String, it checks to see if the receiver supports #to_str (via
> str_to_str). When it's done, the prior check for T_STRING is simply an
> optimization. So it looks like Ruby is moving towards typing by
> interface internally.

Fair enough... but I would still argue that it wouldn't make sense for
#exception to exist if it *only* exists because rb_f_raise() expects
objects to have a particular interface.  If there's some other need or
demand for #exception, that's a different matter -- but my grepping of
the installation suggests that it's not such a hot item.

Mind you, #exception doesn't do any harm -- I'm just wondering whether
it's really needed on the Ruby side.


David

-- 
David Alan Black
home: dblack@candle.superlink.net
work: blackdav@shu.edu
Web:  http://pirate.shu.edu/~blackdav