Paul Sandoz <[EMAIL PROTECTED]> writes:
> >> >> /**
> >> >> * List of defined match items types
> >> >> *
> >> >> */
> >> >> const long matchItemsOneOrMore = 0;
> >> >> const long matchItemsAll = 1;
> >> >>
> >> >
> >> >Would it be worthwhile to design the interfaces to support boolean
> >> >logic (and, or, not, precedence), to allow for future expansion?
> >
> >I'm still curious to hear any thoughts you might have on the above
> >question.
> >
>
> Still thinking on it!
>
> Example:
>
> (name == "X" && nickname == "Y") ||
> (email 'contains' "ZSxsxZ" || !(fax="123"))
>
> Note sure how to do it beyond creating interfaces to
> cater for statements and operators i.e. defining
> a binary tree representing the statement where the
> nodes are operations. Not sure i am using the correct
> terminology but you see these types of things
> when looking at compiler books, if one feels
> so inclined, when referring to parsing statements.
I think the term you're looking for is "expression" rather than
statement. And yeah, a binary tree sounds like just the right
representation.
> Hmm... i see what you are saying though.
>
> How about a statement interface (which is just
> a type with no methods) and a simple statement
> interface which inherits from this.
>
> interface Statement : nsISupports
> {
> };
>
> interface SimpleAndOrStatement: Statement
> {
> attribute nsISupportsArray matchItems;
> attribute long matchItemsType;
> };
>
> The nsIAbDirectoryQueryArguments will then
> contain a statement attribute.
>
> Further inheritance from statement could then
> define unary & binary boolean operations which
> contain statement attributes. A leaf statement
> will be a match item.
I definitely like the idea of having the simple case right now and
then leaving it open for expansion. Hmm, I bet there's some easy way
to specify all the operators as bits of JS code to take advantage of
the fact that JS has full builtin boolean logic already.
> >> Attached is a version with support for nsISupportsArray
> >> and arrays. Additionally added an nsISupports attribute
> >> to the QueryPropertyValue interface if a property
> >> is associated with an interface (e.g. nsIAbCard).
> >
> >Cool; it would be interesting to hear any comments on these from
> >Candice or Ducarroz...
> >
>
> Attached is a synchronous implementation of the existing
> query interfaces which does a linear search over
> the address books, just like auto completion.
> (Sorry no comments i hammered it out yesterday
> real fast).
>
> The class nsAbDirectoryQueryAutoComplete performs
> a query using the same parameters as that for
> the auto complete, see the method:
>
> nsAbDirectoryQueryAutoComplete::Start
>
> The example uses a value of 'paul' for all the
> match items. 3 query results are returned
> (see the moz.gif image for the list of cards
> and the moz.txt file for the output from
> the query listener).
>
> The only thing which is missing is case insensitive
> matching, thus i think an extra boolean attribute
> is required on the match item interface.
Cool. Unfortunately, I don't yet have my head entirely wrapped around
what you're doing (not enough hours in the day :-/ ), so I don't have
much in the way of comments. But it seems like a good direction to
me...
Dan
--
