• Did not look at the code yet, but could imagine - from a design point of view - that putting multiple attributes in a filter object, these attributes work (hopefully?) as AND.

    filter = [{ manufacturerData:{0x0590:{}}}
              , id:"d9:c7:0b:0a:48:20 random"
    NRF.requestDevice({ filters: filters }).then(
        function(d) { 
            if ( d.manufacturerData ) 
                console.log(JSON.parse(String.fromCharCo­de.apply(null, d.manufacturerData)));
    /* output
    =Promise: {  }
    { "w": 2953 }

    If this is not the case or would break backward compatibility, a simple solution for interpretation is to use nested array: arrays of ('OR') filters as array elements are AND of OR-filters:

    Ex: [ [f0,f1,f2...] , [fa,fb,fc,...] ] equals (f0||f1||f2||...) && (fa||fb||fc||...).

    'OR' of 'AND' filters look then like this:

    Ex: [ [ [f0,f1,f2...] , [fa,fb,fc,...] ] , [ [f9,f8,f7...] , [fz,fx,fy,...] ].

    This evaluator has to 'look ahead' (way too far, all the way thru) to determine wether the next element is an OR or AND element (odd or even [] enclosed, and that is bad. Therefore, I hope that multiple properties in a filter work as AND (as stated in the very beginning): [ and ] 'Operators' demarcate an OR expression, { and } demarcate an AND expression, with the AND expression element has a refining, 'deep-peeling' AND ({} - nesting).

    Comparing this to logical expressions, notation of precedence seems inverse: in a mixed and and or logical expression, ANDs have precedence and parenthesis allow to inject ORs as AND elements. As long as nesting stays within 2 levels, the filter evaluator needs only one extra 'accumulator' / variable to hold the temporary result while calculating an inner expression. Going full nested of any depth, requires a stack... and all things become way more complicated


Avatar for allObjects @allObjects started