[PEAK] How do I resolve AmbiguousMethod?

[Daniel Nouri]

Phillip J. Eby wrote:
> At 05:06 PM 1/26/2007 +0100, Daniel Nouri wrote:
>> What's the best way to do what I want to do?
> 
> You can't do it in RuleDispatch without defining a custom method
> combination.  Even then, it would be difficult, because it sounds like
> you're trying to resolve the priority based on something that could
> change on each call of the function.  RuleDispatch can only handle
> statically-determinable rule precedence, i.e., precedences that can be
> computed without reference to the *actual* arguments passed to a
> function.  In other words, given two adapters, if one adapter is
> preferable to another on one call of the function, it must be preferable
> in all cases, assuming it's applicable.

I don't think it's true that my priority of functions changes over the
course of the program execution.

Firsly, Zope choses an adapter because it implements a particular interface.
 But then you can have multiple adapters registered for a particular
interface.  In which case Zope decides to return the adapter that implements
the interface that's closest to the requested one.  That is, if there's an
adapter that implements ``IOne(Interface)`` and one that implements
``ITwo(IOne)``, a call to ``IOne(bar)`` will return the first
implementation.  I haven't actually looked at the implementation of how Zope
determines this nor tried it out, but I guess it's the base class distance.

> Without this condition, you would have to create a method combination
> that dynamically determines which adapter is more suitable at the time
> the function is called.  In other words, your method combination would
> return a wrapper function to do this.

If I'm right, I should still be able to do this and I'll look into method
combinations more closely.  Is there something equivalent in simplegeneric?

> Personally, my suggestion would be to avoid emulating Zope's adapter
> system to begin with.  For stateless adapters, you can just use generic
> functions to begin with, and a lot of complexity goes away just like
> that.  Try using the 'simplegeneric' package on the CheeseShop (which,
> unlike RuleDispatch, is actively developed and supported), and you'll
> find that you can do most of what Zope adapters can do, excluding
> esoterica such as tuple adapters, event adapters, etc. (which require
> something like PEAK-Rules or RuleDispatch in order to emulate them).

My motivation was to try and emulate Zope's adapter system only for my own
education.  IOW, I want to see how much of Zope's adapters I can emulate
"like this" and at which point it gets more complicated, and how those more
 complicated rules would be solved with RuleDispatch.


Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daniel.nouri.vcf
Type: text/x-vcard
Size: 131 bytes
Desc: not available
Url : http://www.eby-sarna.com/pipermail/peak/attachments/20070204/e13a986a/daniel.nouri.vcf