Another neat trick is you can mark these as private so you can use them internally without worrying about them leaking out by throwing a private into the class.
This can be useful if you don't like remembering when to use @year vs year or perhaps you want to be prepared to abstract it later.
require"date"classMovieattr_accessor:name,:yearprivate:year,:year=definitialize(name,year)@name=name@year=yearenddefageDate.today.year-yearendendobj1=Movie.new("Forrest Gump",1994)obj1.year#=> NoMethodError: private method `year' called for #<Movie:....>obj1.year=2018#=> NoMethodError: private method `year=' called for #<Movie:....>obj1.age#=> 24
/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
It can be odd, but it can also be useful as it allows you to more easily override it later without having to go find/replace all instances of @year in your class.
Or, if a class inherits from it and needs to change how year is generated it's easier it doesn't have to worry about parent class using @year.
/developer|entrepreneur/i
Always looking for new developer talent, even those with zero experience, as you never know who's got the potential to become a great developer.
It just seems inconsistent to use year and self.year = ... in the code where one's bare and the other's necessarily prefixed, instead of @year consistently. This plus the way that @year is by default "private".
One of the major goals of object-oriented design is to properly contain any changes like that, so replacing @year with something else is at least contained to the one file or scope.
Subclass concerns are valid, though in Ruby it's generally understood you need to play nice with your parent's properties and avoid really getting in there and wrecking around.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Another neat trick is you can mark these as private so you can use them internally without worrying about them leaking out by throwing a
private
into the class.This can be useful if you don't like remembering when to use
@year
vsyear
or perhaps you want to be prepared to abstract it later.Thanks for sharing !!
It seems odd to declare these as
private
since you can always refer to them by their@
name internally.It can be odd, but it can also be useful as it allows you to more easily override it later without having to go find/replace all instances of
@year
in your class.Or, if a class inherits from it and needs to change how
year
is generated it's easier it doesn't have to worry about parent class using@year
.If that makes sense.
It just seems inconsistent to use
year
andself.year = ...
in the code where one's bare and the other's necessarily prefixed, instead of@year
consistently. This plus the way that@year
is by default "private".One of the major goals of object-oriented design is to properly contain any changes like that, so replacing
@year
with something else is at least contained to the one file or scope.Subclass concerns are valid, though in Ruby it's generally understood you need to play nice with your parent's properties and avoid really getting in there and wrecking around.