RE: [contacts] Comments on editors draft of Contacts API

Le lundi 30 novembre 2009 à 18:05 +0100, a écrit :
> > * I am a bit nervous about using SQL as the formal language 
> > to describe the filtering algorithm; I think given that the 
> > filtering we're doing is rather simple (OR / AND / LIMIT / 
> > OFFSET), I would go with a prose or mathematical description 
> > on the set of known contacts.
> I'm not particularly pleased with the 'Contact Search Processing Rules'
> section for this reason. This is currently highlighted as an editor's
> note. Perhaps you have some examples on which I could draw to rework
> this section?

This may be made moot by the ongoing discussions on drastically
simplifying the search interface, but in case it isn’t, I was thinking
to something along the lines of:

Let contactsset be initially the set of all known contacts
If input is an Array object 
        1. Let multiplefilters be the input parameter being parsed.
        2. Let singlefilter be the next index in mutiplefilters. If
        there are no more indices, go to step 6.
        3. Let filteredcontactsset be the result of processing
        contactsset with singlefilter through the rules for processing
        filter combinations.
        4. Let contactsset be the union of contactsset with
        5. Go to step 2
        6. Return contactsset
If input is an Object object
        1. Let singlefilter be the input parameter being parsed.
        2. Let item be the next enumerable property in singlefilter. If
        there are no more enumerable properties, go to step 10.
        3. If the value of item is null, go to step 2.
        4. Let contactsset be the subset of contactsset whose elements
        have the item attribute set to the value of item
        5. Go to step 2.
        6. Return contactsset.
If input is another native object type
Return a null value.

(I’m not entirely sure this is the correct algorithm, but hopefully it
gives an idea what I had in mind)


Received on Tuesday, 1 December 2009 08:39:23 UTC