Re: Singleton methods on Float and Bignum

On 5/15/2008 1:39 PM, Rick DeNatale wrote:
> On Thu, May 15, 2008 at 5:24 AM, Matthias Wächter
> <matthias <at> waechter.wiz.at> wrote:
>> On 5/15/2008 5:33 AM, Joel VanderWerf wrote:
>>> x = 1.0
>>> def x.foo; end
>>> (1.0).foo   # what should happen here?
>> x="abc"
>> def x.foo; end
>> "abc".foo     # what should happen here?
>>
>> I don't see your point. You can create new objects in various ways, while
>> Strings and Floats just make it easier for you. I don't even see why there
>> is no special built-in type of Fixnum (and nil/true/false) is available that
>> can easily be passed by reference, just for convenience, which would allow
>> applying singletons as well.
> 
> I, on the other hand, have a hard time seeing a motivating use case.
> Consider this admittedly contrived example:
> 
> bignum = 1073741824
> def  1073741824.to_s
>    "Found me!"
> end
> 
> What should happen here:
> 
>   puts bignum + 0
> 
>   puts  32768 * 32768

foo = "foo"
def foo.to_i
  42
end

What should happen here:

n=0+(foo+"matic").to_i
m=42-("f"+"o"+"o").to_i

The current _implementation_ ties Fixnums (and nil/...) to non-objects and strings (i.e. everything
else) to real objects, this is no natural law.

> I daresay that most would be surprised that although 1 is always 1,
> and 10 is always 10, but 1073741824 isn't always 1073741824.

Sure, but "foo" isn't always "foo" either, at least when one of them is already stored in an object, so again
what's the point? Why are Fixnums more holy or have to be more pure than any other object? I can ack every
aspect of optimization related to nil/true/false/symbol/Fixnum and their pass-by-value non-object
behavior, but I don't see the natural law that it has to be this way. Instead, I see good reason at least to
_allow_ pass-by-ref for these objects, and a "singleton socket" for them is just a logical consequence of
this step.

> My point is that we tend to think of numerics primarily in term of
> their value rather than there identity, and singleton classes are tied
> to the identity of the object. 

IMVHO, this comes solely from the implementation and the fact that you cannot pass Fixnum objects around
(or get one back from pass-by-reference) and we got used to writing separate classes for the (rare?)
situations of requiring Fixnum-likes with singleton capabilities or reference passing.

> Now perhaps, if we really wanted to
> attach singleton methods to numerics the ruby implementation could do
> things like:

I wouldn't follow this path. "Just" find a way of imitating object-like behavior for
nil/true/false/symbol/Fixnums if requested by a keyword, find a good way of automatically converting
between them. Or maybe even the other way round: _All_ numbers, nil, true, false, and all symbols are per
definition objects, and use (faster, call-by-val, non-singleton) immediates only if a keyword is
given. Well, a very progressive thought without an idea of implementation or syntax change ...

>     1) Use a lookup table to find the 'singleton' class for Fixnum

>     2) Intern Bignums (and Floats?) so that there's only one instance

We don't do this for strings either, so why should it be something special about Fixnums, Bignums or Floats?

- Matthias