"Aredridel" <aredridel / nbtsc.org> wrote in message

> Would a single method, traverse_component be sufficient to build an
> implementation on, do you think? Pass it a path component, and have the
> object return whatever makes sense? (for a hash or array, map it to [];
> for Objects in general, map it to send?)
>
> Perhaps have a second method, traverse_filter, that receives an array of
> filters, for XPath-style qualifications like [@attr = 'foo'], or
> [/childobject]?

My thoughts ... suppose query was based on 2 kinds of procs, traversers and
filters. Simplest traversers would just do x.send :foo (abbreviated
[:foo]?), simplest filters might just check an attribute value (abbreviated
{:foo=>bar}?).

class Q
    attr_accessor :traverser, :filter
    # traverser: obj->obj
    # filter. obj->bool

We can build paths by composing queries.
    def [](traverser, filter)
        # shortcuts for symbols, hashes, etc.
        Q.new self, traverser, filter
    end
    def initialize prefix, traverser, filter
    end
end

This will let us navigate from an object, and filter an object in or out.
Then perhaps a query-oriented collection.

class QColl
    def eval (query) #-> QColl
        # transitive traverse, filter
        # return new QColl
    end
    def self.wrap(array)
        # wrap new QColl around array
    end

And if we want sugar: collection.foo{|f| f.bar<10}
instead of arr.collect{|x|x.foo}.select{|f| f.bar < 10}

    def method_missing sym, *args, &filter
        self.eval Q.new nil, proc{|x| x.send sym, *args}, filter
    end
end

Thoughts?