[PEAK] Rules override

[Sergey Schetinin]

Maybe it's not a case common enough for inclusion into the library
itself, but I'll try to explain why in my case the new method type was
called for. I use PEAK-Rules in a GUI library, previously it was using
PyProtocols, but the way it is structured it makes a lot of sense to
port it to generic functions. The library has an abstract part and a
concrete implementations (just wx right now), the common part declares
generic functions like enable, disable, resize etc. One of such
functions is add(parent, child) where `child' is usually a template of
a window, something that defines it's type and parameters that would
be common for all implementations of this window type. So in wx
implementation of the library there would be definitions like this:

@when(add, (wx.Window, Button))
def add_button(....)

It's quite handy to be able to add multiple windows at once, like this:

#panel is an existing wx.Panel instance
ok, cancel = add(panel, [Button("OK"), Button("Cancel")])

To make it work I have this definition in common library:

        @override(add, (object, istype(list),))
        @override(add, (object, istype(tuple),))
        def multiapply_add_saveresults(parent, subj):
           return tuple(add(parent, item) for for item in subj)

Why this wouldn't work without ambiguity resolution is because there's
a need for similar wildcard overrides on first parameter. For example
there's a special "parent" class which remembers changes made to it
(adds, resizes, assigned event handlers etc) and when it itself will
be added as a child to something it will replay the same actions on
the new object. This makes for too many cases requiring ambiguity
resolution and there's no downside to simply letting the first
declared override apply.

Why it's safe to assume that the override will resolve the ambiguity
is because it will always call the generic function it overrides with
a different set of parameters changed in such a way that it itself
will no longer apply (and thus generally there will be no infinite
recursion).

A better way to implement this, I think, would be a method type that
can change the parameters passed to the function (an "after" variant
capable of changing the result value would be great as well). I'll try
implementing that when I'll have the time.


On an unrelated note I'll be making a presentation on PEAK-Rules (I
plan to cover some PyProtocols as well) on a local conference
(http://exception.org.ua/). There will be about 400 programmers in the
audience, so not to embarrass myself too much I'm trying to learn the
internals of the library beyond what I need for my own projects.



On Sat, Mar 1, 2008 at 11:40 PM, Phillip J. Eby <pje at telecommunity.com> wrote:
> At 10:07 PM 3/1/2008 +0200, Sergey Schetinin wrote:
>  >Not exactly, the difference is when the ambiguity occurs, `override'
>  >just uses the first one defined. I can't find a better way to
>  >implement multiple dispatch where some of the rules have the priority
>  >over all the other ones and ambiguity is ignored (assumed to be
>  >handled by the methods themselves). See my example in the last
>  >message.
>
>  Yes, I saw it, and I don't understand the use case or why you want to
>  ignore ambiguity or think you can assume it "to be handled by the
>  methods themselves".  (And your example was achievable with 'around'
>  methods as soon as you got rid of the list/list ambiguity -- a good
>  thing to do in any case.)
>
>  Note that even "before" and "after" methods with the same criteria
>  are not truly ambiguous - they use definition order and
>  reverse-definition order to break the ties (using the "precedence"
>  argument, which is a sequentially-generated number).
>
>  And, without a clear use case for it, I don't plan to add another
>  ambiguity-resolving method type.  In general, new users are far too
>  quick to want to resolve ambiguity by precedence hacks, when they
>  should be thinking more deeply about what they are trying to
>  express/accomplish.  Often, a slight refactoring of the function
>  signature or rules creates more clarity in the application, as well
>  as resolving the ambiguity.
>
>



-- 
Best Regards,
Sergey Schetinin

http://s3bk.com/ -- S3 Backup
http://word-to-html.com/ -- Word to HTML Converter