---- 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.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
