Magnitude should be reimplemented as a Trait

> I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another.
>
> Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well.
>
> Additionally, I discovered that this message:
> isMetacelloConfig
> ^ false
>
> needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).<TComparable.st>_______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> thanks this is cool :)
>
> Ideally I would like to have a deep look at the trait implementation and understand also how we can make it more pluggable
> but I do not have the time for that.
>
> Stef
>
> On Aug 29, 2010, at 7:21 AM, jaayer wrote:
>
>> I recently ran into a situation where I needed a class to behave like a subclass of Magnitude, understanding <, <= and company, that could not be a subclass of Magnitude because it already had a custom superclass. I had two options: use composition to create a Magnitude subclass that implements Magnitude's abstract methods by forwarding to an instance of the class in question, or implement all of Magnitude's message in the class. While the first choice was clearly preferable to the second, I would have liked to have had a third: use a Trait to graft comparability on to the class. While I know some people here dislike Traits, I don't think a class should have to inherit from Magnitude just so its instances can be easily compared with one another.
>>
>> Enclosed is a fileout of a Trait named TComparable. It contains Magnitude's "comparing" and "testing" messages with the argument names and method comments changed where needed. If Magnitude is to be reimplemented using it, then Magnitude's class template must be changed accordingly, and perhaps its old implementations of the "comparing" and "testing" messages should be removed as well.
>>
>> Additionally, I discovered that this message:
>> isMetacelloConfig
>>       ^ false
>>
>> needs to be added to Trait, if it hasn't been already, otherwise you get an error when right-clicking on one (at least in 1.1).<TComparable.st>_______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>I'm not comfortable with English, but to me Magnitude is about
>ordering rather than just comparing.
>I expect a TOrderable to describe a fully or partially ordered set.
>If you define this, then it is a fully ordered set:
><= aMagnitude
>    ^(self > aMagnitude) not
>
>Beware, due to introduction of NaN, Float is not fully ordered, this
>require overriding above message in Number.
>
>Nicolas

>
>
> ---- On Sun, 29 Aug 2010 07:28:19 -0700 Nicolas Cellier  wrote ----
>
>> I'm not comfortable with English, but to me Magnitude is about
>> ordering rather than just comparing.
>> I expect a TOrderable to describe a fully or partially ordered set.
>> If you define this, then it is a fully ordered set:
>> <= aMagnitude
>>     ^(self > aMagnitude) not
>>
>> Beware, due to introduction of NaN, Float is not fully ordered, this
>> require overriding above message in Number.
>>
>> Nicolas
>
> Comparable has parallels in other languages like Java and C#'s Comparable and IComparable interfaces. Also, one of its categories is "comparing."
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
>
> ---- On Mon, 30 Aug 2010 03:32:18 -0700 Stéphane Ducasse  wrote ----
>
>> +1
>> So this is ok :)
>> What I would love in my wildest dream is to have magnitude using TComparable :)
>> But this may be too complex.
>> I would like to have the time to check how we can make trait implementation leaner, smaller.....
>>
>> Stef
>
> Actually, if you change Magnitude's class definition to this:
>
> Object subclass: #Magnitude
> uses: TComparable
> instanceVariableNames: ''
> classVariableNames: ''
> poolDictionaries: ''
> category: 'Kernel-Numbers'
>
> and then manually remove its "comparing" and "testing" messages, everything seems to work. (Same number of passed/failed tests in "KernelTests-Numbers" as before ) But I could see this potentially causing build issues.