[PEAK] Rules override

[Sergey Schetinin]

Um, regarding the more powerful before / after that wouldn't solve the
issue with ambiguity and dispatching to multiple calls, but it's still
useful to make porting some parts of protocols-based code more
straightforward.

On Sun, Mar 2, 2008 at 10:48 AM, Sergey Schetinin <maluke at gmail.com> wrote:
> 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
>



-- 
Best Regards,
Sergey Schetinin

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