incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <n...@verse.com>
Subject Re: [lucy-dev] FieldType Equals() and class membership
Date Thu, 03 Mar 2011 04:54:26 GMT
On Wed, Mar 2, 2011 at 5:18 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
>> My only thought would be that it might be better not to mentally overload
>> the name Equals.
>
> We use Equals() and Hash_Sum() the way that several other object systems do:
> objects for which Equals() returns true must produce identical values for
> Hash_Sum().  This allows us to use many different kinds of objects as hash
> keys.

I agree that is is common practice.  I was questioning, though,
whether it was best practice.  But when it comes to OO techniques,
it's hard for me to tell whether I'm a canary in the coal mine or just
a mad dog barking at the moon.  I felt I should bring it up, but I'll
trust your instinct.

>> While I'm nitpicking, is the '!!' really necessary there?  I'm not
>> sure how these fields are being used, but is it certain that one
>> always wants to consider things the same if these have different
>> values?
>
> Those members you're referring to have boolean values.
>
>    if (!!self->indexed    != !!evil_twin->indexed)    return false;
>
> Since C doesn't provide a boolean type with values restricted to true and
> false, using !! provides an extra level of safety, insulating this method from
> a glitch elsewhere in the code.  Whether that's appropriate caution or
> paranoia is a matter for debate.  :)

I understand what it does, but wondered if it was being
_insufficiently_ paranoid.  Hypothetically, who knows why, but someone
might try:

#define INDEXED_BASIC 1
#define INDEXED_EXTRA 2
BasicType->indexed = INDEXED_BASIC;
ExtraType->indexed = INDEXED_EXTRA;

What should FieldType_Equals() return?  If one was being fully
paranoid, one might conclude that if the values are anything other
than numerically (not logically) equal, that it's always safer to
return false rather than taking any risk of corrupting the index.
Currently, the 'error' is silently 'fixed'.  I was wondering if this
is really a good thing.  I'd personally probably do it numerically and
might even add an ASSERT(indexed == !!index) somewhere, but I can get
a little ASSERT happy at times.

Nathan Kurz
nate@verse.com

Mime
View raw message