"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
By the way, I recently came across a use case for @around that I
hadn't mentioned before. I'm in the process of re-implementing
RuleDispatch's expression features in PEAK-Rules, and as I was
defining the rules for intersecting logical conditions, it occurred
to me that you could define intersection in terms of
implication. When intersecting conditions A and B, you can return A
if it implies B, or B if it implies A.
So I just wrote this (translated here to the PEP 3124 dialect):
@around(intersect)
def intersect_if_implies(c1:object, c2:object, nm:next_method):
if implies(c1, c2):
return c1
elif implies(c2, c1):
return c2
return nm(c1, c2)
Because this method is @around, it is called before any ordinary
methods are called, even if they apply to more specific types than
'object'. This means you only have to define intersection algorithms
to handle conditions that don't imply each other. (Assuming of
course you've defined implies() relationships.)
When I realized I could do this, I was able to ditch a bunch of
duplicated code in the individual intersect() relationships I had,
and avoided having to write that code for the rest of the intersect()
methods I had left to write.
=====================================
As a side note: if you have either a negate() or disjoint(), you can also
handle a 3rd of the 4 cases object-generically:
elif disjoint(c1,c2): return <empty> #or
elif implies(c1, negate(c2): return <empty> # symmetrical with
elif implies(c2, negate(c1): trturn <empty>
and then the intersection algorithms can assume non-disjointness.
tjr
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
