lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] FieldType Equals() and class membership
Date Thu, 03 Mar 2011 01:18:09 GMT
On Wed, Mar 02, 2011 at 04:40:45PM -0800, Nathan Kurz wrote:
> On Wed, Mar 2, 2011 at 4:07 PM, Marvin Humphrey <> wrote:
> > For some classes, e.g. CharBuf, Equals() should emphatically *not* test for
> > class membership, so that e.g. a CharBuf and a ViewCharBuf with the same
> > logical content test as equal.  For FieldType, I can't think of a scenario
> > where having objects which belong to different classes test as equal would be
> > desirable.
> All sounds reasonable and like good changes.  

Cool, thanks for thinking it through.

> 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

Off the top of my head, I know that Python, Java, Ruby, and C# all provide
similar contracts:

    Python:  __hash__, __eq__
    Java:    hashCode, equals
    Ruby     hash, eql?
    C#       GetHashCode, Equals

Perl and Javascript are the odd ones out, since they limit their hash keys to
string types.

> Maybe FType_SameClass() would be clearer?

It's not uncommon to provide variants on equals() methods -- for example, Ruby
provides the following:

I think that the semantics of FieldType's Equals() method fit within
traditional definitions pretty well: we want to know whether these objects
have the same value.  We don't want to allow two different FieldType objects
which produce different index formats to be conflated.  There can be only one
index format per field name, therefore there can be only one FieldType per
field name in a Schema.  This is very similar to the problem of testing
whether one key should should displace another within a set/hashset.

> 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.  :)

Marvin Humphrey

View raw message