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:
=
+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,
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,
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
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
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
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
