[Pharo-project] 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).
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 Pharo-project@lists.gforge.inria.fr 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 2010/8/29 Stéphane Ducasse <stephane.ducasse@inria.fr>:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
---- 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."
+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 On Aug 30, 2010, at 12:11 PM, jaayer wrote:
---- 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 Pharo-project@lists.gforge.inria.fr 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. Also, Magnitude's "testing" messages, despite what their category name implies, do not return booleans; instead they return other Magnitudes. I have recategorized those messages (#min:, #max:, and #min:max:) in TComparable under "comparing" in the attached fileout.
On Aug 30, 2010, at 1:25 PM, jaayer wrote:
---- 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.
Excellent!!!!! I would not have dare doing it. We are trying to get the system bootstrap and bumping in a lot of issues and shaking the system. So I was implying more that. I'm also thorn apart about the pluggability of traits - my meta sin. :) http://code.google.com/p/pharo/issues/detail?id=2884
Also, Magnitude's "testing" messages, despite what their category name implies, do not return booleans; instead they return other Magnitudes. I have recategorized those messages (#min:, #max:, and #min:max:) in TComparable under "comparing" in the attached fileout.<TComparable2.st>_______________________________________________
Indeed http://code.google.com/p/pharo/issues/detail?id=2882
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (3)
-
jaayer -
Nicolas Cellier -
Stéphane Ducasse