On Aug 11, 2007, at 09:17, Vincent Hennebert wrote:
<snip />
Good idea, much better than the above! Didn't quite occur to me to do
that. Then again, in case you didn't notice: those lines are
removed...(?)
Ok, I isolated the wrong snippet... Go below in the commit message,
and
you’ll find plenty of such lines with plus instead of minus :-P
Yeah, I knew that... ;-)
<snip/>
All that said... if most methods of the Numeric interface aren’t
applicable to EnumNumber, should that class still be considered as
a Numeric object? Does that make sense to cast an EnumNumber into
a Numeric?
Well, apparently, a long time ago, someone felt it necessary to
have a
Property type that stored an enum but in the end it's only a number
(values like "no-limit").
The idea of an EnumNumber itself always seemed somewhat ugly to
me, but
I never took the time to come up with a decent alternative.
So we can consider that this class will eventually be removed/changed?
Then this hack is more acceptable. What about a “TODO this is ugly and
shall be removed”?
Also a fine suggestion. Now that the point has been raised, I'm
trying to assess why it currently needs to exist in the first place.
Maybe we could even do without, which would be even better. It just
looked a little like EnumNumber is an artificial construction to have
an Enum that can act as a Numeric (?), and in that case it seemed
cleaner to me to implement the Numeric interface than have it extend
NumberProperty just to override those methods that aren't supposed to
be called anyway...
EnumLength is another one of those hybrids, BTW.
Cheers
Andreas
