[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