Hi,
Actually the MaDateIndex was used in some real work.
It mught be prudent to accept a tested patch to the MaDateIndex that, conditionally, allows null date values.
Since this null feature will probably crop up in a lot of index classes, it might be prudent to agree on a naming convention.
E.g. index := MaDateIndex new acceptNulls; yourself.
Chris should have the final word on the naming IMHO.
Cheers
Brent
From: asqueaker@gmail.com To: nmanzanos@gmail.com, Subject: FW: Re: Nil in an index Date: Sat, 12 Jan 2008 22:48:11 -0500
The indexes provided with Magma are really just simple examples. Robust applications will almost certainly want to define their own custom indexes.
That is your path to a clean solution. Make your own DateIndex that accepts a nil. Just override #canIndex: in addition to #indexHashForIndexObject:, et al...
On Jan 11, 2008 9:43 AM, Norberto Manzanos nmanzanos@gmail.com wrote:
Hi!
Is it a good idea avoid nil in magma indexes? This question rised when I tried MaDateIndex. Until this moment, I
used
String or Integer indexes having care to answer allways a String
(an empty
string if the object is nil) and an Integer (a zero if nil). But
with dates
there is a conceptual problem: there is not a null date. In some applications, business stuff, for example, you can think in an
ovbiously
unused date (01-01-1500, for example) that acts as a null date.
It's a
little dirty, but it would work. But in other applications every
possible
date has a meaning. And if the object could be inexistent in some
cases, you
have no choice: it's nil. That's my case, and I'm forced to use a StringIndex, converting the
dates to
Strings, answering an empty string if the object is nil. That's
really
dirty. Would'nt be better if magma indexes just ignore nil objects? Is it a requirement for magma that every object from a MagmaCollection must
be
present in all indexes? I hope there is something I misunderstood and there is a more
elegant
solution.
Regards Norberto
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
_______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Interesting idea. Should acceptNulls mean, "ignoreNulls" or are you suggesting the index should support "null" (can we say nil?) as an indexable position? Presumably the lowest possible hash value, 0 (zero)?
Probably the former because usually the presence of a non-nil value is what is interesting about the object. The ones with nil are not interesting w.r.t. that index.
Right?
On Jan 14, 2008 4:15 AM, brent@zamail.co.za wrote:
Hi,
Actually the MaDateIndex was used in some real work.
It mught be prudent to accept a tested patch to the MaDateIndex that, conditionally, allows null date values.
Since this null feature will probably crop up in a lot of index classes, it might be prudent to agree on a naming convention.
E.g. index := MaDateIndex new acceptNulls; yourself.
Chris should have the final word on the naming IMHO.
Cheers
Brent
From: asqueaker@gmail.com To: nmanzanos@gmail.com, Subject: FW: Re: Nil in an index Date: Sat, 12 Jan 2008 22:48:11 -0500
The indexes provided with Magma are really just simple examples. Robust applications will almost certainly want to define their own custom indexes.
That is your path to a clean solution. Make your own DateIndex that accepts a nil. Just override #canIndex: in addition to #indexHashForIndexObject:, et al...
On Jan 11, 2008 9:43 AM, Norberto Manzanos nmanzanos@gmail.com wrote:
Hi!
Is it a good idea avoid nil in magma indexes? This question rised when I tried MaDateIndex. Until this moment, I
used
String or Integer indexes having care to answer allways a String
(an empty
string if the object is nil) and an Integer (a zero if nil). But
with dates
there is a conceptual problem: there is not a null date. In some applications, business stuff, for example, you can think in an
ovbiously
unused date (01-01-1500, for example) that acts as a null date.
It's a
little dirty, but it would work. But in other applications every
possible
date has a meaning. And if the object could be inexistent in some
cases, you
have no choice: it's nil. That's my case, and I'm forced to use a StringIndex, converting the
dates to
Strings, answering an empty string if the object is nil. That's
really
dirty. Would'nt be better if magma indexes just ignore nil objects? Is it a requirement for magma that every object from a MagmaCollection must
be
present in all indexes? I hope there is something I misunderstood and there is a more
elegant
solution.
Regards Norberto
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org
-
brent＠zamail.co.za -
Chris Muller