This really surprises me:
3.instance_variable_set("@unbelievable", "believe it!")
puts 3.instance_variable_get("@unbelievable") # -> "believe it!"
which led me to:
class Fixnum
attr_accessor :note
end
13.note = "a baker's dozen"
25.note = "5 squared"
notes = [13, 21, 25].collect { |x| x.note } # ["a baker's dozen", nil, "5 squared"]
Am I the only person with their jaw on the ground?
Gary Wright
that is very cool.
('a'..'z').each_with_index { |letter,index| index.note = letter }
That was my first little random hack, but I imagine there are more
possibilities here 
On 12/30/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
class Fixnum
attr_accessor :note
end
Am I the only person with their jaw on the ground?
When I discovered this, what surprised me was not so much that you
could do this, but that can do this _even_though_ you can't give them
singleton methods (or access their singleton classes).
I just assumed the reason was because the singleton classes are stored
in some structure that immediate values don't have, but that instance
variables are stored separately in some other way. (I never looked at
the interpreter source to verify this, though.)
So the question in my mind: Is there a reason we couldn't do that
with ints, too?
Chris
On 12/30/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
Am I the only person with their jaw on the ground?
I'm pretty sure some of the crusty old rubyists here would say, Not being
surprised about this is a first step towards ruby master... 
That one got me, too. I kind of hinted at it in some nuby code I wrote (http://roscopeco.co.uk/code/noob/bitwise.html\). Also check out:
irb(main):001:0> class Symbol
irb(main):002:1> attr_accessor :too
irb(main):003:1> end
=> nil
irb(main):004:0> :foo.too
=> nil
irb(main):005:0> :foo.too = 66
=> 66
irb(main):006:0> :foo.too
=> 66
This struck me as pretty cool, too:
irb(main):007:0> SomethingElse = Symbol
=> Symbol
irb(main):008:0> :foo.is_a? SomethingElse
=> true
God, Ruby is *good*
On Fri, 30 Dec 2005 07:46:17 -0000, <gwtmp01@mac.com> wrote:
This really surprises me:
3.instance_variable_set("@unbelievable", "believe it!")
puts 3.instance_variable_get("@unbelievable") # -> "believe it!"
which led me to:
class Fixnum
attr_accessor :note
end13.note = "a baker's dozen"
25.note = "5 squared"notes = [13, 21, 25].collect { |x| x.note } # ["a baker's dozen", nil, "5 squared"]
Am I the only person with their jaw on the ground?
--
Ross Bamford - rosco@roscopeco.remove.co.uk
class Fixnum
attr_accessor :note
end13.note = "a baker's dozen"
25.note = "5 squared"notes = [13, 21, 25].collect { |x| x.note } # ["a baker's dozen",
nil, "5 squared"]
It's really cool.
--
Posted via http://www.ruby-forum.com/\.
class Object
def foo
"foo"
end
class <<self
def bar
"bar"
end
end
end
examples:
"Some string".foo
-> "foo"
Bignum.bar
-> "bar
On Fri, 30 Dec 2005 09:57:09 +0100, Chris Pine <chris@pine.fm> wrote:
On 12/30/05, gwtmp01@mac.com <gwtmp01@mac.com> wrote:
Am I the only person with their jaw on the ground?
When I discovered this, what surprised me was not so much that you
could do this, but that can do this _even_though_ you can't give them
singleton methods (or access their singleton classes).I just assumed the reason was because the singleton classes are stored
in some structure that immediate values don't have, but that instance
variables are stored separately in some other way. (I never looked at
the interpreter source to verify this, though.)So the question in my mind: Is there a reason we couldn't do that
with ints, too?Chris
Welcome to Monkey Patching! This is how ActiveResource gives you things
like:
4.days.ago
"some string".underscore
and the like.
It's one of the many things that makes Ruby code very fun to write.
Jason
On Jan 5, 2008 10:07 AM, Barca Junior <wuzhengchun@gmail.com> wrote:
>
> class Fixnum
> attr_accessor :note
> end
>
> 13.note = "a baker's dozen"
> 25.note = "5 squared"
>
> notes = [13, 21, 25].collect { |x| x.note } # ["a baker's dozen",
> nil, "5 squared"]
>It's really cool.
--
Posted via http://www.ruby-forum.com/\.
No, I meant giving the Fixnums themselves singleton methods, like this:
irb(main):001:0> a = 'hello'
=> "hello"
irb(main):002:0> def a.hi
irb(main):003:1> 'hi'
irb(main):004:1> end
=> nil
irb(main):005:0> a.hi
=> "hi"
irb(main):006:0> b = 5
=> 5
irb(main):007:0> def b.howdy
irb(main):008:1> 'howdy'
irb(main):009:1> end
TypeError: can't define singleton method "howdy" for Fixnum
from (irb):7
irb(main):010:0> 
Why not??
So I can do it for a string, but not a fixnum (or any other immediate object).
That's what surprised me. You can have instance variables for 5, but
not singleton methods for 5. (Of course you can have methods for 5,
but if 5 responds to it, then 6 does, too.)
Cheers,
Chris
On 12/30/05, Pete <pertl@gmx.org> wrote:
class Object
def foo
"foo"
end
class <<self
def bar
"bar"
end
end
end
Actually it is a bit different. Monkey patching is just adding
methods to classes. Fixnum and String in your examples.
Instance variables on Fixnums (or Symbols or Nil) is different.
It is a good example of uniformity in Ruby but I'm hard pressed
to think of a nice use case for the feature.
Gary Wright
On Jan 5, 2008, at 10:15 AM, Jason Roelofs wrote:
Welcome to Monkey Patching! This is how ActiveResource gives you things
like:4.days.ago
"some string".underscore
and the like.
It's one of the many things that makes Ruby code very fun to write
Quoting http://www.rubygarden.org/faq/entry/show/83 :
"Fixnums, Symbols, true, nil, and false are implemented as immediate values. With immediate values, variables hold the objects themselves, rather than references to them.
Singleton methods cannot be defined for such objects. Two Fixnums of the same value always represent the same object instance, so (for example) instance variables for the Fixnum with the value "one" are shared between all the "ones" is the system. This makes it impossible to define a singleton method for just one of these."
~ ryan ~
On Dec 30, 2005, at 6:39 AM, Chris Pine wrote:
On 12/30/05, Pete <pertl@gmx.org> wrote:
class Object
def foo
"foo"
end
class <<self
def bar
"bar"
end
end
endNo, I meant giving the Fixnums themselves singleton methods, like this:
irb(main):001:0> a = 'hello'
=> "hello"
irb(main):002:0> def a.hi
irb(main):003:1> 'hi'
irb(main):004:1> end
=> nil
irb(main):005:0> a.hi
=> "hi"
irb(main):006:0> b = 5
=> 5
irb(main):007:0> def b.howdy
irb(main):008:1> 'howdy'
irb(main):009:1> end
TypeError: can't define singleton method "howdy" for Fixnum
from (irb):7
irb(main):010:0>So I can do it for a string, but not a fixnum (or any other immediate object).
That's what surprised me. You can have instance variables for 5, but
not singleton methods for 5. (Of course you can have methods for 5,
but if 5 responds to it, then 6 does, too.)Cheers,
Chris
You can use it to cache the result of method calls.
class Fixnum
def factorial
@factorial ||= self * (self-1).factorial
end
end
0.instance_variable_set('@factorial',1)
On Jan 5, 2008 4:32 PM, Gary Wright <gwtmp01@mac.com> wrote:
Actually it is a bit different. Monkey patching is just adding
methods to classes. Fixnum and String in your examples.Instance variables on Fixnums (or Symbols or Nil) is different.
It is a good example of uniformity in Ruby but I'm hard pressed
to think of a nice use case for the feature.Gary Wright
Two Fixnums of
the same value always represent the same object instance, so (for
example) instance variables for the Fixnum with the value "one" are
shared between all the "ones" is the system.
Makes sense so far. Then we get this:
This makes it impossible
to define a singleton method for just one of these."
What!? The implementation makes it impossible, not the fact that
every 1 in the system refers to the same object. The constant
"Object" refers to the same object (the Object class) every time I
write it; this certainly doesn't prevent one from writing singleton
methods for it.
I'm not sure what the original author of that was trying to say, but I
think the real answer is just that, for whatever implementation
reasons (most likely for the sake of optimization), immediate objects
can't have singleton methods.
Again, my guess is that the choice was make to store singleton methods
(or the pointer to the singleton class) in some "ruby object" struct
that immediate values don't have. But what I find surprising (going
all the way back to the beginning is that, given this, we can still
define instance variables. The reason for this must be that instance
variables are stored elsewhere (not in this "ruby object" struct, but
in some other data store). But this seems an odd choice. I would
have thought that both the klass pointer (as I think they call it) and
the instance variables are stored in that struct. Maybe GC had
something to do with this design... I can't say more without looking
at the source.
(Isn't this usually where Guy steps in with an email consisting of 4
words and the exact lines of the interpreter code?
Chris
On 12/30/05, J. Ryan Sobol <ryansobol@gmail.com> wrote:
Without thinking too hard about it and without looking at the
source code, I would guess that it is not supported to avoid
the overhead of a method search for individual objects. You
still have to do the method search for the class and as such
you can extend the class but the search for a per/object
method is avoided.
Gary Wright
On Dec 30, 2005, at 4:10 PM, Chris Pine wrote:
I'm not sure what the original author of that was trying to say, but I
think the real answer is just that, for whatever implementation
reasons (most likely for the sake of optimization), immediate objects
can't have singleton methods.
(Isn't this usually where Guy steps in with an email consisting of 4
words and the exact lines of the interpreter code?
[ruby-talk:17321]
Guy Decoux