Your example is quite unusual. The scope of the 'person_instance' variable is only going to be within your class definition of Person. Basically you are creating several instances but then discarding any reference to them. After the 'end' that terminates the Person definition 'person_instance' won't be defined and so the instance won't be accessible.
It is important to realize that Ruby class definitions are actually executable code. The code within the class..end block is executed in the order it is written so that by the time you get to your "Person.new" calls, the class is defined as well as 'initialize' and 'printit' so there isn't anything magical going on when you call Person.new.
Note, that if you moved your Person.new calls to between the definition of initialize and printIt, they would fail because they would be executed before printIt was defined.
Gary Wright
···
On Feb 26, 2011, at 8:29 PM, Marc Chanliau wrote:
In Ruby it seems you can instantiate a class inside the class itself or
outside. What is the accepted convention?
In the following example, instantiation is inside the class:
class Person
attr_accessor :name, :age, :gender
def initialize(name, age, gender) @name = name @age = age.to_i @gender = gender
end
# method to print a new person
def printIt
print " "
print name
print ", "
print age
print ", "
print gender
puts
end
# generating instances and printing them from inside the class itself
person_instance = Person.new("Jessica", 17, "female")
person_instance.printIt
person_instance = Person.new("Marc", 60, "male")
person_instance.printIt
person_instance = Person.new("Linda", 56, "female")
person_instance.printIt
In Ruby it seems you can instantiate a class inside the class itself or
outside.
that's ok, if you want to be my-class-centric rather than ruby's main
centric. downside is, you cannot create instances of your
class-centric class outside without invoking your class-centric
instances inside that class-centric class. in short, you're losing
some ease-of-use features. but hey, maybe that is what you want and
have a use for it, and ruby happily does not prevent you
What is the accepted convention?
this is ruby. either there are no rules nor convention, or there are many
best regards -botp
···
On Sun, Feb 27, 2011 at 9:29 AM, Marc Chanliau <marc.chanliau@gmail.com> wrote:
Your example is quite unusual. The scope of the 'person_instance'
variable is only going to be within your class definition of Person.
Basically you are creating several instances but then discarding any
reference to them. After the 'end' that terminates the Person
definition 'person_instance' won't be defined and so the instance won't
be accessible.
It is important to realize that Ruby class definitions are actually
executable code. The code within the class..end block is executed in the
order it is written so that by the time you get to your "Person.new"
calls, the class is defined as well as 'initialize' and 'printit' so
there isn't anything magical going on when you call Person.new.
Note, that if you moved your Person.new calls to between the definition
of initialize and printIt, they would fail because they would be
executed before printIt was defined.
Gary Wright
Thanks, that's the type of explanation I was looking for. In summary,
always instantiate outside the class (you probably can tell I'm coming
from Java).
There is no "always do this" type of rule... We encourage understanding and experimentation and best practices to the limits of our understanding.
If your class was simply to output some values who's to say you can't instantiate variables inside the class definition...
His code is just fine... Personally I'd never write code like that because it doesn't support reuse very well and every time the class is defined and run, it prints out some stuff which isn't very helpful in all contexts.
Julian
···
On 27/02/2011, at 1:32 PM, botp <botpena@gmail.com> wrote:
On Sun, Feb 27, 2011 at 9:29 AM, Marc Chanliau <marc.chanliau@gmail.com> wrote:
In Ruby it seems you can instantiate a class inside the class itself or
outside.
that's ok, if you want to be my-class-centric rather than ruby's main
centric. downside is, you cannot create instances of your
class-centric class outside without invoking your class-centric
instances inside that class-centric class. in short, you're losing
some ease-of-use features. but hey, maybe that is what you want and
have a use for it, and ruby happily does not prevent you
What is the accepted convention?
this is ruby. either there are no rules nor convention, or there are many
