headers
Evan Phoenix | 15 May 03:59
Gravatar

Singleton methods on Float and Bignum

In 1.8 (and 1.9 likely), trying to add a singleton method to a Float  
or Bignum raises a TypeError, even though they aren't immediates.

Tracking it back, I see that the function num_sadded contains a comment:

/* Numerics should be values; singleton_methods should not be added to  
them */

Is this still true? Is there a real reason to not allow methods  
singleton methods to be added to Float or Bignum instances?

  - Evan Phoenix
Permalink | Reply |
headers
Dave Thomas | 15 May 04:24
Favicon
Gravatar

Re: Singleton methods on Float and Bignum


On May 14, 2008, at 9:02 PM, Evan Phoenix wrote:
> Is this still true? Is there a real reason to not allow methods  
> singleton methods to be added to Float or Bignum instances?

Would it slow down dispatch on coercion?

Dave
Permalink | Reply |
headers
Joel VanderWerf | 15 May 05:33
Picon

Re: Singleton methods on Float and Bignum

Evan Phoenix wrote:
> Is this still true? Is there a real reason to not allow methods 
> singleton methods to be added to Float or Bignum instances?

x = 1.0
def x.foo; end
(1.0).foo   # what should happen here?

Would floats be stored in some kind of table, like symbols, so that the 
last line works? If so, every float returned by a method would have to 
be looked up in the table to get the unique float object. No?

If, OTOH, each float instance, regardless of #==, can respond to 
different methods, then there is a major abstraction leak.

--

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
Permalink | Reply |
headers
Evan Phoenix | 15 May 06:25
Gravatar

Re: Singleton methods on Float and Bignum


On May 14, 2008, at 8:33 PM, Joel VanderWerf wrote:

> Evan Phoenix wrote:
>> Is this still true? Is there a real reason to not allow methods  
>> singleton methods to be added to Float or Bignum instances?
>
> x = 1.0
> def x.foo; end
> (1.0).foo   # what should happen here?

Good point. #foo only existed on the instance created by the '1.0'  
syntax returned to 'x'.

So the justification would be that because there is syntax for them,  
each time they appear the same in syntax should behave exactly the  
same? That seem right?

>
>
> Would floats be stored in some kind of table, like symbols, so that  
> the last line works? If so, every float returned by a method would  
> have to be looked up in the table to get the unique float object. No?
>
>
> If, OTOH, each float instance, regardless of #==, can respond to  
> different methods, then there is a major abstraction leak.
>
> -- 
>      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407
(Continue reading)

Permalink | Reply |
headers
Matthias Wächter | 15 May 11:24
Picon

Re: Singleton methods on Float and Bignum

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.

- Matthias
Permalink | Reply |
headers
Rick DeNatale | 15 May 13:39
Picon

Re: Singleton methods on Float and Bignum

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
(Continue reading)

Permalink | Reply |
headers
Matthias Wächter | 15 May 14:08
Picon

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
(Continue reading)

Permalink | Reply |
headers
Kurt Stephens | 16 May 20:45

Re: Singleton methods on Float and Bignum


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

Because they are value classes and value objects should be immutable in
value and behavior.

Preserving the immutability of objects used as values has implications
for memoizing computations.

Examples:

Ruby Strings are not immutable and it causes significant memory issues,
made worse by the fact that each lexical String "constant" allocates a
new String object.  Immediates like Fixnums are not allocated thus
object identity is preserved and operations on Fixnums can be memoized
using object identity as a cache key.

Why doesn't Symbol#to_s return a memoized frozen String?  A Symbol's
name cannot be changed by definition, yet Symbol#to_s returns a new
String each time even if the caller never intends to mutate it.

Mutability of the result of to_s an String "constants" is a programmer
convenience, but it has significant performance implications: consider
that String "" interpolation uses to_s to coerce to String values that
it never mutates.
(Continue reading)

Permalink | Reply |

Gmane