< :the previous in number
^ :the list in numerical order
> :the next in number
P :the previous aricle (the previous thread)
N :the next (in thread)
|<:the previous thread
>|:the next thread
^ :the parent (reply-to)
_:the child (an article replying to this)
>:the elder article having the same parent
<:the youger article having the same parent
---:split window and show thread lists
| :split window (vertically) and show thread lists
~ :close the thread frame
.:the index
..:the index of indices
As Ruby beginner, i try some "canonical" OO scripts. Doing so, I've
noticed some strange behaviour in inheritance mechanism (from my point
of vue). Considering a base class Employee :
class Employee
attr_reader :name, :age, :salary
attr_writer :name, :age, :salary
def initialize(name, age, salary)
@name = name
@age = age
@salary = salary
end
def to_s
"Name: #{@name}, #{@age}, #{@salary}"
end
end
Considering Manager, an Employee's subclass
class Manager < Employee
attr_reader :grade
attr_writer :grade
def initialize(name, age, salary, grade)
super(name, age, salary)
@grade = grade
end
def to_s
super + ", #{@grade}"
end
end
A Manager "is a" Employee, reverse is not true (that's the classical
assertion...)
In Ruby, it's legal to assign an Manager to an Employee with
anEmployee = aManager
anEmployee is now a Manager... I know Ruby doesn't care about type
checking and i'm aware of the fact that both names are references,
but, when it comes to classes, it hurts my inheritance conception. Is
there a way to avoid this behaviour or is it a "feature" ?
--
?ric Jacoboni, n? il y a 1296955303 secondes