Newbie question

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

On Feb 26, 2011, at 8:29 PM, Marc C. wrote:

@gender = gender
puts
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 W.

Gary W. wrote in post #984168:

On Feb 26, 2011, at 8:29 PM, Marc C. wrote:

@gender = gender
puts
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 W.

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

Actually it depends what you want to do.

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 Sun, Feb 27, 2011 at 9:29 AM, Marc C. [email protected]
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 :slight_smile:

What is the accepted convention?

this is ruby. either there are no rules nor convention, or there are
many :slight_smile:

best regards -botp

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs