[Pharo-project] Smells looking at collections
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? Saludos! Nico. blog: nicopaez.wordpress.com
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?
This was the original hierarchy: Magnitude -> LookupKey -> Association. Someone removed LookupKey from the chain. This was LookupKey's comment: "I represent a key for looking up entries in a data structure. Subclasses of me, such as Association, typically represent dictionary entries." Levente
Saludos! Nico. blog: nicopaez.wordpress.com
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 2010/10/22 Levente Uzonyi <leves@elte.hu>
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?
This was the original hierarchy: Magnitude -> LookupKey -> Association. Someone removed LookupKey from the chain. This was LookupKey's comment:
"I represent a key for looking up entries in a data structure. Subclasses of me, such as Association, typically represent dictionary entries."
Levente
Saludos! Nico. blog: nicopaez.wordpress.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
---- On Fri, 22 Oct 2010 04:56:28 -0700 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?
Saludos! Nico. blog: nicopaez.wordpress.com
There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is.
On Sat, 23 Oct 2010, jaayer wrote:
---- On Fri, 22 Oct 2010 04:56:28 -0700 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?
Saludos! Nico. blog: nicopaez.wordpress.com
There was a discussion here a few weeks ago concerning a Trait I proposed called TComparable. It is the protocol of Magnitude bundled separately as a Trait, so any class can behave like Magnitude without having to inherit from Magnitude or use composition. You need only add "uses: TComparable" to the class template and then override its abstract methods as needed, and instances of your class will now be comparable. Association could use TComparable rather than inheriting from Magnitude, and, if the build system permits, Magnitude itself could be rewritten to use TComparable. Stef. approved of the idea and expressed a desire to see it in upcoming versions of Pharo, but I am not sure what the current status is. That's a nice solution, but it means that Traits have to be in the Kernel. I have three problems with Traits: 1) they are stateless 2) they are different from classes 3) incomplete tools support (this may be fixed in Pharo, but I doubt it is) Levente _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
jaayer -
Levente Uzonyi -
Mariano Martinez Peck -
Nicolás Paez