[Reality] Containment - barriers to implementation

exarkun at divmod.com exarkun at divmod.com
Sun Apr 4 22:27:20 MDT 2004


On Sun, 4 Apr 2004 03:01:23 -0400, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:
>
> On Apr 4, 2004, at 1:33 AM, <exarkun at divmod.com> wrote:
> 
> > As an alternative to adding a second criterion, it also seems possible 
> > to change the current criterion to an introspectable object ... which 
> > would provide enough information to filter both collectors/more and 
> > implements/find in semantically different ways.  This preserves the 
> > existing interfaces, more or less, and forces us to fix criterion 
> > sooner rather than later, so maybe is a better solution.
> 
> IMHO this is the correct solution, because I have a feeling we will 
> want the criterion to do more sophisticated things as time goes on, and 
> I don't want to go from 2 to 3 to 4 kinds of criterion in doing so.

  I suspected this was the case.  I am trying to come up with concrete examples of how one of these criterion objects would be implemented and having a fairly difficult time of it.

  Briefly, I thought different types of criterion objects could be used when collecting different interfaces,  Unfortunately it seems that radix and I demolished that possiblity at PyCon by calling the criterion object in _collect():

def _collect(asker, start, interface, criterion, radius=2):
    seen = {}
    selfish = interface(start, default=None)
    if selfish is not None and criterion(selfish):
        yield (0, selfish)
        seen[id(selfish)] = True
    for distance, collector in _evermore(start, asker, interface, criterion, radius):
        for implementor in collector.find(asker, interface, criterion):
            if id(implementor) not in seen:
                yield distance, implementor
                seen[id(implementor)] = True

  The change fixed a bug where too many objects were being collected.  Maybe there is another way to accomplish the same thing without using the criterion object.

> 
> A good example of "more stuff" might be a 'refine' method on criterion 
> to aggregate them, whereby one might (somehow) indicate that one is 
> requesting an object *both* whose name is "sword" *and* whose owner is 
> me.
> 

  So, here's a random thought for the structure of the criterion object:

    criterion = [
        (common.INoun, 'name', lambda o: o == 'sword'),
        (something.IPosession, 'owner', lambda o: o is glyph),
    ]

  Of course, this only allows for one kind of logical boolean connector.  A possible fix would be to build up a tree representing the criteria, e.g.:

    criterion = AND(
        (common.INoun, 'name', lambda o: o == 'sword'),
        (something.IPosession, 'owner', lambda o: o is glyph)
    )

  with all the other obvious callables such as OR, NOT etc.  This adds a pretty hefty burden to the implementors of find() and more() though.

  Better ideas (please)?

  Jp



More information about the Reality mailing list