On the quickstart tutorial on the Ruby homepage, http://www.ruby-lang.org/en/quickstart/3/ , it says,
"In Ruby, you can open a class up again and modify it. That doesn't
change any objects that already exist, but it does affect any new
objects you create." This is incorrect. For example:
irb(main):001:0> class FooClass; end
nil
irb(main):002:0> sally = FooClass.new
#<FooClass:0xb7e0b214>
irb(main):003:0> class FooClass; def foo; puts "bar"; end; end
nil
irb(main):004:0> sally.foo
bar
nil
Changing a class changes the objects of that class which already exist
(which is pretty cool).
On the quickstart tutorial on the Ruby homepage, http://www.ruby-lang.org/en/quickstart/3/ , it says,
"In Ruby, you can open a class up again and modify it. That doesn't
change any objects that already exist, but it does affect any new
objects you create." This is incorrect. For example:
Nope, this is correct.
This in fact changes the object behaviour, but the objects themselves are not changed. Methods belongs to classes, not objects.
oinkoink wrote:
> On the quickstart tutorial on the Ruby homepage,
> http://www.ruby-lang.org/en/quickstart/3/ , it says,
> "In Ruby, you can open a class up again and modify it. That doesn't
> change any objects that already exist, but it does affect any new
> objects you create." This is incorrect. For example:
Nope, this is correct.
This in fact changes the object behaviour, but the objects themselves
are not changed. Methods belongs to classes, not objects.
lopex
The problem is that the tutorial suggests that objects which have
already been created before a class is modified are affected
differently from objects which are created after the class is modified.
The problem is that the tutorial suggests that objects which have
already been created before a class is modified are affected
differently from objects which are created after the class is modified.
Ok, let's put it another way. Modifying a class doesn't change two thins
- instance variables of existing objects
- anything that is stored in singleton/eigen/meta/whatever class
You can define a method that belongs only to certain object and is not stored in the object's class:
class Foo
def bar
p "bar"
end
end
f = Foo.new
# defining a method on an object (it is stored in a special class that belongs _only_ to f)
def f.bar
p "my_bar"
end
# redefining an instance method, class is changed
class Foo
def bar
p "new_bar"
end
end
# not affected:
f.bar
-> "my_bar"
but new instances will have the new Foo#bar method
What you are saying is correct, the problem is just that the tutorial
is *definitely* saying the same thing you are
Any existing objects are affected by changes to the class.
This should be corrected or, if they actually *did* intend to say what
you have said here, 'clarified' with a heavy hand.
···
On 2006.10.05 07:50, Marcin Miel??y??ski wrote:
oinkoink wrote:
>The problem is that the tutorial suggests that objects which have
>already been created before a class is modified are affected
>differently from objects which are created after the class is modified.
>
Ok, let's put it another way. Modifying a class doesn't change two thins
- instance variables of existing objects
- anything that is stored in singleton/eigen/meta/whatever class
The problem is that the tutorial suggests that objects which have
already been created before a class is modified are affected
differently from objects which are created after the class is modified.
Ok, let's put it another way. Modifying a class doesn't change two thins
- instance variables of existing objects
- anything that is stored in singleton/eigen/meta/whatever class
It does if the class being changed is a singleton class But
anyway...the point is that the tutorial is misleading, because, as
oinkoink points out, it suggests that existing objects and future
objects relate differently to the class (see the "but" in the middle
of the sentence, in particular; whatever terms are being used
["changed", "affected", etc.], there's clearly a contrast being
suggested).
