On 04/08/11 20:12, Robert Klemme wrote:
> On Fri, Apr 8, 2011 at 9:30 AM, Clifford Heath<no / spam.please.net>  wrote:
>> On 04/07/11 19:19, Robert Klemme wrote:
>>> On Thu, Apr 7, 2011 at 6:05 AM, Clifford Heath<no / spam.please.net>    wrote:
>>> I also doubt whether it is a good idea to allow for subclassing of an
>>> integer like class.  What use case do you have in mind which would
>>> make this necessary?
>> What's wrong with the case you use in that blog post?
> You mean, make HexNum a subclass of Integer?  Yes, actually that's
> what I had attempted at the time but failed for technical reasons

No, I don't mean making HexNum a subclass of Integer, but making it an
"integer like class" which can be subclassed.

> (explained in the blog).  As it turns out it's generally not necessary
> to inherit Integer in Ruby to create a class which behaves like an
> integer (most of the time).

Right. I'd like to see that work *more* of the time :). Or at least,
that each Ruby interpreter should fail in the same way.

>> I suspect that you "doubt it is a good idea" only because Ruby's object
>> model for numbers is inconsistent, and you're defensive about that.
> Where exactly do you see the inconsistency?  I can see that a few
> things in that area do not match common expectations.  But I don't
> think it's really inconsistent.

By inconsistent, I mean that Ruby doesn't make it possible to make
subclasses of Integer that play nicely with other Integers. Fixnum
and Bignum are mutually compatible and automatically and invisibly
convert back and forth, but it's not possible for an user's class to
do the same. That's inconsistent. A few more calls to coerce and some
more circumspect interpreter optimisations and it would all be pretty
ok.

Note that I expect there will still be a need for Java-style boxed
and unboxed integer values. C# makes the boxing even more transparent
than Java,  but Ruby doesn't even try.

> Your problem is not so much with numeric classes IMHO but rather with
> implementations of class Hash in different versions of Ruby.  Namely
> do they have issues treating instances from different class as
> equivalent.

Yes. It's documented to use #hash and #eql?, so that's what it should do.
If it also has invisible optimisations, fine. So long as they're invisible.

> Fixnum and Bignum do not share common values so you never have
> instances of different classes representing the same numeric integer
> value:

Yes. But I never need to know where the cut-over is, and it can be different
with different Ruby build targets. It's almost completely transparent.

> Apparently there are optimizations done under the hood (similarly to
> duping an unfrozen String as key)

Except that the case of String is documented, and works the same in all
interpreters.

> which is probably OK from a
> pragmatic point of view (what you attempt seems rather seldom done).

Mainly because it doesn't work :)

Clifford Heath.