Maybe I am so naive, but what are the advantages of such Inheritance?
The only thing I see is that in all your code of Association you can do "self " and access to all the behavior of Magnitude.
But it is not that difficult to use composition, and write "self aMagnitude"
replace aMagnitude for whatever name you want.
Cheers
mariano
This was the original hierarchy: Magnitude -> LookupKey -> Association. Someone removed LookupKey from the chain. This was LookupKey's comment:On Fri, 22 Oct 2010, Nicol�s Paez wrote:
Hi, I was looking at collection packages and I found that the class
Association inherits from Magnitude.
It is really strange for me because inheritance represent a "is-a" relation.
So I looked that the documentation of each of these classes:
*Association:* I represent a pair of associated objects--a key and a value.
My instances can serve as entries in a dictionary.
*Magnitude:* I'm the abstract class Magnitude that provides common protocol
for objects that have
the ability to be compared along a linear dimension, such as dates or times.
Subclasses of Magnitude include Date, ArithmeticValue, and Time, as well as
Character and LookupKey.
Based on this, I think this relation is conceptually WRONG.
If the idea is to reuse code then composition should be used instead of
inheritance.
What do you think?
"I represent a key for looking up entries in a data structure. Subclasses of me, such as Association, typically represent dictionary entries."
Levente
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project