Newbie question

[Marc Chanliau]

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

end

 

[Gary Wright]

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:
=20
class Person
attr_accessor :name, :age, :gender
=20
def initialize(name, age, gender)
@name =3D name
@age =3D age.to_i
@gender =3D gender
end
=20
# method to print a new person
def printIt
print " "
print name
print ", "
print age
print ", "
print gender
puts
end
=20
# generating instances and printing them from inside the class itself
person_instance =3D Person.new("Jessica", 17, "female")
person_instance.printIt
person_instance =3D Person.new("Marc", 60, "male")
person_instance.printIt
person_instance =3D Person.new("Linda", 56, "female")
person_instance.printIt
=20
end

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

 

[Marc Chanliau]

Gary Wright wrote in post #984168:

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).

 

[botp]

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

 

[Julian Leviston]

Actually it depends what you want to do.

There is no "always do this" type of rule... We encourage understanding and e=
xperimentation 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 instan=
tiate variables inside the class definition...=20

His code is just fine... Personally I'd never write code like that because i=
t doesn't support reuse very well and every time the class is defined and ru=
n, it prints out some stuff which isn't very helpful in all contexts.

Julian