On 03.02.2007 12:49, gga wrote:
>> Note that you generally should not use #kind_of? and like methods (->
>> Duck Typing).
> 
> I understand what you want to say but to have a class behave EXACTLY
> like a numeric class, it should mimic the behavior of those functions,
> too.  By using delegation, I'm forced to do two checks for it, which
> sucks.

Duck Typing is all about *not* checking.

> which means Fixnum has some place where it stores additional methods
> and data and its "copy constructor" knows how to properly duplicate
> the whole class, without me needing to use dup.  Which means to me
> Numerics SHOULD be inheritable as is.

Instead of ranting about things that do not work the way you want it you 
may achieve better results by adjusting to the way things are.  It's not 
that what you want is impossible.  You seem to be stuck in some other 
language's / environment's mindset and apparently you did not embrace 
Ruby yet.

>> The way to go is delegation, as
>> you did.
> 
> I know, but I am trying NOT to.  Doing so is a big mess.  Plus, I
> don't get any additional methods other users may add to Numeric or
> Fixnum or have to rely on method_missing which then blocks you from
> calling the original's Numeric method_missing (bad idea).

(see above)

>> You can however inherit any of the other classes in the
>> inheritance chain of Fixnum:
>>
>> irb(main):006:0> 1.class
>> => Fixnum
>> irb(main):007:0> 1.class.ancestors
>> => [Fixnum, Integer, Precision, Numeric, Comparable, Object, Kernel]
>>
>> One of Integer, Precision or Numeric seems most appropriate.
> 
> You think I have not tried it? Try any of these:
> 
> Fixnum.new(20)
> Integer.new(20)
> Precision.new(20)
> Numeric.new(20)
> 
> ALL of them are abstract classes, without a new method.  You simply
> CANNOT inherit from any numeric class (or, to put it more correctly,
> you can, but you cannot instantiate the object afterwards which makes
> this kind of useless). Period.  It still makes no sense to me why, and
> seems more like a big issue to me.

Ooops, you're right.  Sorry for the bad advice.  Even defining new does 
not help because there is no allocate.  Alas, you don't need inheritance 
because of Ruby's dynamic nature.  There's a documented way to implement 
numeric classes that play nicely with built in types - and it works.

> Delegate is pretty weak.  The ancestors method, for example, is not
> handled correctly.

For good reasons.

>> Also, if you want to do math you should implement #coerce.  Note that
>> unary operators have an at appended:
> 
> Well.  That's the kind of stuff I was HOPING to avoid by inheriting
> from it.  Numeric#coerce as is should work fine for my own class.  I
> shouldn't have to rewrite it (or several other functions, for that
> matter).  I should, of course, have to rewrite operators that return
> the original base type, but not everything else.

I don't believe you can use Numeric.coerce since it does not know 
anything about your class.  All the math etc. will be broken.

I try differently: what kind of class do you want to implement?  Why do 
you think you need to inherit?  What capabilities should instances of 
your class have?

Regards

	robert