Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-28 Thread Jim Fulton


On Sep 28, 2007, at 11:14 AM, Martijn Faassen wrote:
...

On 9/28/07, Jim Fulton [EMAIL PROTECTED] wrote:
[snip]

we could investigate whether we can't come up with something that:

* doesn't break the existing notation. The cleanest way to support
such non-interference seems to be to do this using an extra .adapt
method. This is unfortunate, as I at least consider it prettier if
it used the IFoo() syntax (even though I proposed .adapt).


I agree.


Hm, you agree with my evaluation, but would this mean you'd suggest we
use 'adapt' or extend the __call__ syntax?


In the short-to-medium term the adapt method is my preference.

...


After thinking about it, I think I can avoid the extra hook.  Don't
worry about the details. :)


Cool! The person that tries to implement this will have to worry about
them, though, so we'll get back to you on that, I'm sure.


Yup.

...


Do you suggest we extend zope.component with support for this, or
would you suggest we indeed create a new package?


You'll need to modify InterfaceClass to add the new adapt method and  
__call__ semantics. The hook installed by zope.component will need to  
be updated as well.  I see no new package being warrented.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-28 Thread Martijn Faassen
Hey,

First: thanks for listening, Jim.

On 9/28/07, Jim Fulton [EMAIL PROTECTED] wrote:
[snip]
  we could investigate whether we can't come up with something that:
 
  * doesn't break the existing notation. The cleanest way to support
  such non-interference seems to be to do this using an extra .adapt
  method. This is unfortunate, as I at least consider it prettier if
  it used the IFoo() syntax (even though I proposed .adapt).

 I agree.

Hm, you agree with my evaluation, but would this mean you'd suggest we
use 'adapt' or extend the __call__ syntax?

  * creates a small a new hook inside zope.interface to support this

 After thinking about it, I think I can avoid the extra hook.  Don't
 worry about the details. :)

Cool! The person that tries to implement this will have to worry about
them, though, so we'll get back to you on that, I'm sure.

 BTW, we *could* use interface __call__ for utility lookup, as there
 would be no conflict with current notation *if* we specified a
 default using a keyword argument.
 I would far prefer using

IFoo() or IFoo(default=None)

 to look up a utility over:

IFoo.adapt() or IFoo.adapt(default=None)

 for, I hope, obvious reasons.

Agreed. This is good argument for using the __call__ syntax.

 I'd also like to support specifying a default for adapter lookup via
 a keyword argument.  In fact, I'd like to deprecate passing the
 default positionally.  This would open the door, sometime in the
 future, to allowing multi-adaptation via: IFoo(ob1, ob2).

+1

  So, any volunteers to try to implement this?

 I insist on reviewing any change before checking it in.  This will
 create an unavoidable bottle neck.

Understood. Work will be done on a branch.

Do you suggest we extend zope.component with support for this, or
would you suggest we indeed create a new package?

Regards,

Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-28 Thread Martijn Faassen

Dominik Huber wrote:
It would be great, if we could handle other adaption-derivations by the 
proposed unified, reasonable adaption-api too.

[snip interesting proposal]

Okay, so there seems to be quite a bit of consensus for *some* form of 
support for this. I've seen a number of proposals which to me look quite 
reasonable.


Since Jim doesn't like this much but there seems to be a lot of support 
from others, we could investigate whether we can't come up with 
something that:


* doesn't break the existing notation. The cleanest way to support such 
non-interference seems to be to do this using an extra .adapt method. 
This is unfortunate, as I at least consider it prettier if it used the 
IFoo() syntax (even though I proposed .adapt).


* creates a small a new hook inside zope.interface to support this

* can be plugged in by an optional extension, like zope.interfacextended

* implements the proposed new features. I like the idea of also allowing 
utility lookup through the same mechanism.


The goal is to support this notation in applications. Of course, as soon 
as a library or framework starts to depend on this extension Jim will 
run into it if he starts to use them, but that happens in all kinds of 
ways otherwise anyway.


So, any volunteers to try to implement this?

Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-28 Thread Jim Fulton


On Sep 28, 2007, at 10:31 AM, Martijn Faassen wrote:


Dominik Huber wrote:
It would be great, if we could handle other adaption-derivations  
by the proposed unified, reasonable adaption-api too.

[snip interesting proposal]

Okay, so there seems to be quite a bit of consensus for *some* form  
of support for this. I've seen a number of proposals which to me  
look quite reasonable.


Since Jim doesn't like this much but there seems to be a lot of  
support from others,


And am willing, therefore, to compromise


we could investigate whether we can't come up with something that:

* doesn't break the existing notation. The cleanest way to support  
such non-interference seems to be to do this using an extra .adapt  
method. This is unfortunate, as I at least consider it prettier if  
it used the IFoo() syntax (even though I proposed .adapt).


I agree.



* creates a small a new hook inside zope.interface to support this


After thinking about it, I think I can avoid the extra hook.  Don't  
worry about the details. :)




* can be plugged in by an optional extension, like  
zope.interfacextended


See above.

* implements the proposed new features. I like the idea of also  
allowing utility lookup through the same mechanism.


I don't, but I'm willing to give in to popular demand.

BTW, we *could* use interface __call__ for utility lookup, as there  
would be no conflict with current notation *if* we specified a  
default using a keyword argument.

I would far prefer using

  IFoo() or IFoo(default=None)

to look up a utility over:

  IFoo.adapt() or IFoo.adapt(default=None)

for, I hope, obvious reasons.

I'd also like to support specifying a default for adapter lookup via  
a keyword argument.  In fact, I'd like to deprecate passing the  
default positionally.  This would open the door, sometime in the  
future, to allowing multi-adaptation via: IFoo(ob1, ob2).



So, any volunteers to try to implement this?


I insist on reviewing any change before checking it in.  This will  
create an unavoidable bottle neck.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-27 Thread Dominik Huber

Brandon Craig Rhodes wrote:

Tres Seaver [EMAIL PROTECTED] writes:


Martijn Faassen wrote:


IFoo.adapt() for normal adaptation
IFoo.multiadapt() for multi adaptation

I'd rather have 'adapt' take *args for the contexts, and keywords
for extras (like name).


And you could make the default= another possible extra!  In which
case our proposals at the moment compare something like this:

 Brandon
  Utility?  IFoo()
  Single adaptation IFoo(a)
  ... with default  IFoo(a, default=y)
  Multi adaptation  IFoo(multi=(a,b))
  ... with default  IFoo(multi=(a,b), default=y)
  Named multi adapter   IFoo(multi=(a,b), name='z')
  ... with default  IFoo(multi=(a,b), name='z', default=y)


This syntax is pretty comfortable because you get code completion for 
free if you are using an ide (ex. eclipse pydev).


At the moment IFoo() invokes the factory of an object (if registered). 
IMO the current implementation is a miss-feature because you can't 
assign any parameters. I would prefer that IFoo() does look up the 
default utility and IFoo(name='z') the named one.


But this change could break existing code.


 Martijn/Tres
  Utility   IFoo.adapt()
  Single adaptation IFoo.adapt(a)
  ... with default  IFoo.adapt(a, default=y)
  Multi adaptation  IFoo.adapt(a,b)
  ... with default  IFoo.adapt(a,b, default=y)
  Named multi adapter   IFoo.adapt(a,b, name='z')
  ... with default  IFoo.adapt(a,b, name='z', default=y)

Well, I have to admit, yours are a lot prettier.  The word adapt
takes no more characters than my multi, and parenthesis disappear!
And though I might quibble that adapt() would be better spelled
utility(), there is a nice symmetry about your idea.

 - Both patterns make it explicit to anyone reading the code when a
   default value is being passed, which should vastly reduce surprise.

+1


 - Mine feels more natural and Pythonic to people who, like PvW in his
   book, think of adaptation as being like casting.

+1



--
Dominik Huber

Perse Engineering GmbH
Alte Landstrasse 6
CH-4658 Däniken

Telefon +41 56 500 01 40
Direkt +41 56 500 01 41
E-Mail [EMAIL PROTECTED]
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-27 Thread Dominik Huber

Marius Gedminas wrote:

On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote:

Why does the caller care?  She just wants an object which will provide
the 'IFoo' contract on behalf of the passed context.  If 'x' is capable
of providing 'IFoo' without help, then failing (or worse, returning a
less-specific factory result) when calling 'getAdapter' is the Wrong
Thing (a least surprise violation, if nothing else).


FWIW it was a big surprise to me when I discovered that IFoo(x) has
different semantics from getAdapter(x, IFoo).


That's true. I spent hours debugging errors related to the adaption 
mechanism. The different api's and its differing lookup mechanism is 
only one piece in the collection of obscurities. Other pieces are caused 
by different frameworks that using the underlying adaption mechanism: 
One problem is that sometimes implemented or adapted objects got treated 
in different way (ex. form-framework: it's modified event notification). 
Another problem is that an adapted context might not locatable if its 
adapter does not implement ILocation or does not get location proxied 
implicitly (ex. local/global security).


All those examples and solutions are based on assumptions about 
implementations and that is causing the adaption-voodoo.


Lookup by interfaces and therefore the adaption asserts a higher logical 
abstraction layer which should encapsulate such implementation details 
(like adaption-, localisation- and lookup-mechanism) in a *reasonable* 
way. If code that relies on this abstraction has to differ the 
underlying mechanism and the kind of the result, it is *necessary* to 
provide an api that covers those needs - IOW why should the caller care 
or make voodoo if he gets what he wants?


It would be great, if we could handle other adaption-derivations by the 
proposed unified, reasonable adaption-api too.


Example using the IFoo()-syntax:

Single adaptation IFoo(a)
... with default  IFoo(a, default=y)
... assert location   IFoo(a, default=y, locate=True)
... no conform-call   IFoo(a, default=y, coform=False)
... force adaptionIFoo(a, default=y, force_adaption=True)
... explicit context  IFoo(a, context=specific_context)

Multi adaptation  IFoo(multi=(a,b))
... with default  IFoo(multi=(a,b), default=y)
Named multi adapter   IFoo(multi=(a,b), name='z')
... with default  IFoo(multi=(a,b), name='z', default=y)
... assert location   IFoo(multi=(a,b), default=y, locate=True)


Regards,
Dominik
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Brandon Craig Rhodes
Jim Fulton [EMAIL PROTECTED] writes:

 On Sep 26, 2007, at 10:04 AM, Brandon Craig Rhodes wrote:

 Instead, multi-adaption should look like this:

   IFoo(multi=(obj1, obj2))
   IFoo(multi=(obj1, obj2), name='site_foo')

 Ah, using keyword arguments to get around limitations (especially
 backward compatibility issues) with the current API is a neat idea.
 If we were going to do this though, I think a method syntax would be
 cleaner.  As in:

   IFoo.adapt([ob1, ob2], 'site_foo', None)

-1.

Unfortunately the singular verb adapt makes it look like normal
adaptation is what is being called for - it looks here like you are
trying to adapt a list to the IFoo interface.

Maybe .multiadapt()?

 Note that IFoo(ob) has some special semantics that don't apply to
 the multi- or named-adapter case.

Agreed!  The semantics are different.  But mightn't we simply document
this difference between single- and multi-adaptation everywhere we
need to, rather than letting it force us into splitting the adapter
syntax into two unwieldy pieces?  I would not imagine that I would be
confused encountering documenting that said:

Call IFoo(x) to adapt a single object x to the IFoo interface,
and IBar(multi=(x,y)) to have the adapter registry find and invoke
a multi-adapter that adapts the pair of objects x and y to the
IBar interface.  When performing single adaptation, the object x
itself is simply returned if it already offers the IFoo interface;
and if the object offers a __conform__ method, then this is called
with the IFoo interface as its argument in place of the normal
adaptation machinery.

So, I am not sure that I see yet the problem with mixing APIs.

For me, the essential issue is that in both single- and multi-
adaptation you are returned an instance of an adapter that has been
instantiated with the objects you are adapting.  Both of these
syntaxes:

IFoo(x)
IBar(multi=(x,y))

suggest this fact, even to the novice Python programmer, because they
make it look like something is being instantiated with the arguments
given, and returned.  Doesn't the benefit of such clarity and symmetry
outweigh whatever slight awkwardness might exist in the sort of
documentation I suggested above?

 An added complication is that interfaces don't provide adaption
 directly, but via a hook. The existing hook api wouldn't work for
 mult or named adaptation, so a new hook would be needed.

I had assumed that IBar(multi=(obj1, obj2)) would simply dispatch to
the existing getMultiAdapter() call; how, exactly, would hooks get
involved and complicate things?  Feel free to just cite a line number
and tell me to go read, all I need is a pointer to get started
understanding this.

-- 
Brandon Craig Rhodes   [EMAIL PROTECTED]   http://rhodesmill.org/brandon
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Jim Fulton


On Sep 26, 2007, at 11:08 AM, Brandon Craig Rhodes wrote:


Jim Fulton [EMAIL PROTECTED] writes:


On Sep 26, 2007, at 10:04 AM, Brandon Craig Rhodes wrote:


Instead, multi-adaption should look like this:

  IFoo(multi=(obj1, obj2))
  IFoo(multi=(obj1, obj2), name='site_foo')


Ah, using keyword arguments to get around limitations (especially
backward compatibility issues) with the current API is a neat idea.
If we were going to do this though, I think a method syntax would be
cleaner.  As in:

  IFoo.adapt([ob1, ob2], 'site_foo', None)


-1.

Unfortunately the singular verb adapt makes it look like normal
adaptation is what is being called for - it looks here like you are
trying to adapt a list to the IFoo interface.

Maybe .multiadapt()?


Note that IFoo(ob) has some special semantics that don't apply to
the multi- or named-adapter case.


Agreed!  The semantics are different.  But mightn't we simply document
this difference between single- and multi-adaptation everywhere we
need to, rather than letting it force us into splitting the adapter
syntax into two unwieldy pieces?


I don't consider either unwieldy.

...


So, I am not sure that I see yet the problem with mixing APIs.


The semantics of the call would change in fundamental ways based on  
the arguments passed. I think this is very bad.  If you disagree,  
sorry. :)




For me, the essential issue is that in both single- and multi-
adaptation you are returned an instance of an adapter that has been
instantiated with the objects you are adapting.  Both of these
syntaxes:

IFoo(x)
IBar(multi=(x,y))


Actually, that is not the case.  If x already provides IFoo, then in  
the first case, the existing object is retuned. Nothing is  
instantiated.  OTOH, in:


  getMultiAdapter([x], IFoo)

or
  getAdapter(x, IFoo)

either there is an error or some factory will be called.  x won't be  
returned unless the factory happens to return it.


...


An added complication is that interfaces don't provide adaption
directly, but via a hook. The existing hook api wouldn't work for
mult or named adaptation, so a new hook would be needed.


I had assumed that IBar(multi=(obj1, obj2)) would simply dispatch to
the existing getMultiAdapter() call; how, exactly, would hooks get
involved and complicate things?  Feel free to just cite a line number
and tell me to go read, all I need is a pointer to get started
understanding this.


zope.interface does *not* depend on zope.component.  It only does  
adaptation the way it does because it provides a hook that  
zope.component fills.  Other people are using zope.interface with  
different adaptation schemes.


Adding multi- or named- adaption support would require a similar hook.

I don't really have time to continue this discussion.  You made a  
reasonable proposal, but for various reasons I've tried to explain, I  
don't support it.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Martijn Faassen

Hey,

My opinions:

It'd be nice if getMultiAdapter's functionality was in reach without 
typing: import zope.component; zope.component.getMultiAdapter. The 
IFoo() single adapter lookup shows us a way to make this possible: a 
method (in this case __call__ on the interface). It does bother me on 
occasion that I need to invoke multi adaptation in such an entirely 
different way. I must also note that it's a very common intuition to 
want to do something like IFoo((a, b)).


Even though  my intuition is usually like Jim's and prefer to have two 
different methods, given different semantics, I consider the differences 
 in semantics here such a grey area I'm on the fence.


That the object itself is returned if it already provides the interface 
in single adaptation is a difference in semantics, but since there's 
just no possibility of doing so in the case of multi adaptation anyway, 
you can argue whether this is a difference in semantics or not, just 
some semantics that doesn't apply. __conform__ is a bigger difference, 
but given that polymorphism abounds in object oriented code, having 
different behavior with different inputs is not *that* surprising either.


Anyway, if we want to split methods, I'm fine with a properly named 
method for multi-adaptation on the interface. For completeness' sake 
you'd also want a properly named method on the interface for 
single-adaptation.


IFoo.adapt() for normal adaptation
IFoo.multiadapt() for multi adaptation

sound reasonable to me. We then explain that if you call IFoo directly, 
IFoo.adapt is called. These could then also be extended to support named 
adapter lookup and such.


Since Jim is -0 on his variation, he's not really against it, if someone 
else does the work, right? :)


Regards,

Martijn

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Dieter Maurer
Jim Fulton wrote at 2007-9-26 11:29 -0400:
 ...
 IFoo(x)
 IBar(multi=(x,y))

Actually, that is not the case.  If x already provides IFoo, then in  
the first case, the existing object is retuned. Nothing is  
instantiated.  OTOH, in:

   getMultiAdapter([x], IFoo)

or
   getAdapter(x, IFoo)

either there is an error or some factory will be called.  x won't be  
returned unless the factory happens to return it.

Is this not an irrelevant implementation detail?

Should I not concentrate on: I get an object related to x
implementing IFoo?



-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Jim Fulton


On Sep 26, 2007, at 3:00 PM, Dieter Maurer wrote:


Jim Fulton wrote at 2007-9-26 11:29 -0400:

...

IFoo(x)
IBar(multi=(x,y))


Actually, that is not the case.  If x already provides IFoo, then in
the first case, the existing object is retuned. Nothing is
instantiated.  OTOH, in:

  getMultiAdapter([x], IFoo)

or
  getAdapter(x, IFoo)

either there is an error or some factory will be called.  x won't be
returned unless the factory happens to return it.


Is this not an irrelevant implementation detail?


No, the specified behavior is different.

Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Dieter Maurer
Jim Fulton wrote at 2007-9-26 15:10 -0400:
 ...
 Jim Fulton wrote at 2007-9-26 11:29 -0400:
 ...
 IFoo(x)
 IBar(multi=(x,y))

 Actually, that is not the case.  If x already provides IFoo, then in
 the first case, the existing object is retuned. Nothing is
 instantiated.  OTOH, in:

   getMultiAdapter([x], IFoo)

 or
   getAdapter(x, IFoo)

 either there is an error or some factory will be called.  x won't be
 returned unless the factory happens to return it.

 Is this not an irrelevant implementation detail?

No, the specified behavior is different.

Hm. But getAdapter and getMultiAdapter may return x as well
(when the factory decides to do this).

Thus, why is it relevant?



-- 
Dieter
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Jim Fulton


On Sep 26, 2007, at 3:37 PM, Dieter Maurer wrote:


Jim Fulton wrote at 2007-9-26 15:10 -0400:

...

Jim Fulton wrote at 2007-9-26 11:29 -0400:

...

IFoo(x)
IBar(multi=(x,y))


Actually, that is not the case.  If x already provides IFoo,  
then in

the first case, the existing object is retuned. Nothing is
instantiated.  OTOH, in:

  getMultiAdapter([x], IFoo)

or
  getAdapter(x, IFoo)

either there is an error or some factory will be called.  x  
won't be

returned unless the factory happens to return it.


Is this not an irrelevant implementation detail?


No, the specified behavior is different.


Hm. But getAdapter and getMultiAdapter may return x as well
(when the factory decides to do this).

Thus, why is it relevant?


Because they don't take into account what x already provides.  They  
will always call some factory.   Also, they never call __conforms__.


Jim

--
Jim Fulton
Zope Corporation


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Derek Richardson
To add a novice's perspective:

When I first learned Zope, I tried the syntax:

adapter = IFoo(context1, context2)

It took me hours and the help of Philipp to determine why context2 was being
returned. I saw the symmetry between IFoo(context) and a cast in other
languages and figured I'd just cast multiple contexts to an adapter. This
makes intuitive sense to the newbie. Returning the second argument as the
default adapter was strange to me, a seeming violation fo the explicit
comparisons to a cast (see the Summary on page 196 of Philipp's book, fourth
bullet point).

As a more experienced Zope developer, I never make this mistake. But I still
yearn for a simple syntax that makes multi-adaption as easy as adaption.
While IFoo.adapt() and IFoo.multiadapt() are nice, neither is as simple as
saying:

adapter = IFoo((context1, context2), default)

So, there seem to be advantages here for both the newbie and the experienced
developer. Martijn notes the advantage for the experienced; I am noting the
it just does what I expect simplicity for the newbie. (of course, I'd
prefer the cast syntax didn't have a default option at all, so it was really
like a cast, but what's done is done).

I don't pretend to understand Jim's objections, as I don't have that mastery
of the z3 internals. But, I plead for you all to see this from a user's
perspective, not from that of the internals. It is expected, for a user,
that adapting (context1, context2) would not return context1 as the adapter,
even if it already implements the interface, because one is attempting
MULTI-adaption. As for what is called internally, as a user of z3, I'm not
sure it matters, as long as I get the adapter back that I expect or a
default or error otherwise.

At the least, I guess, if z3 isn't going to change, the rhetoric of
comparing the adaptation syntax to a cast should change, since, to a
neewbie, the exceptions are confusing and, in my course of learning, were
not clear.

Derek

On 9/26/07, Martijn Faassen [EMAIL PROTECTED] wrote:

 Hey,

 My opinions:

 It'd be nice if getMultiAdapter's functionality was in reach without
 typing: import zope.component; zope.component.getMultiAdapter. The
 IFoo() single adapter lookup shows us a way to make this possible: a
 method (in this case __call__ on the interface). It does bother me on
 occasion that I need to invoke multi adaptation in such an entirely
 different way. I must also note that it's a very common intuition to
 want to do something like IFoo((a, b)).

 Even though  my intuition is usually like Jim's and prefer to have two
 different methods, given different semantics, I consider the differences
   in semantics here such a grey area I'm on the fence.

 That the object itself is returned if it already provides the interface
 in single adaptation is a difference in semantics, but since there's
 just no possibility of doing so in the case of multi adaptation anyway,
 you can argue whether this is a difference in semantics or not, just
 some semantics that doesn't apply. __conform__ is a bigger difference,
 but given that polymorphism abounds in object oriented code, having
 different behavior with different inputs is not *that* surprising either.

 Anyway, if we want to split methods, I'm fine with a properly named
 method for multi-adaptation on the interface. For completeness' sake
 you'd also want a properly named method on the interface for
 single-adaptation.

 IFoo.adapt() for normal adaptation
 IFoo.multiadapt() for multi adaptation

 sound reasonable to me. We then explain that if you call IFoo directly,
 IFoo.adapt is called. These could then also be extended to support named
 adapter lookup and such.

 Since Jim is -0 on his variation, he's not really against it, if someone
 else does the work, right? :)

 Regards,

 Martijn

 ___
 Zope3-dev mailing list
 Zope3-dev@zope.org
 Unsub:
 http://mail.zope.org/mailman/options/zope3-dev/derek.richardson%40gatech.edu

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Stephan Richter
On Wednesday 26 September 2007 15:51, Derek Richardson wrote:
 As a more experienced Zope developer, I never make this mistake. But I
 still yearn for a simple syntax that makes multi-adaption as easy as
 adaption. While IFoo.adapt() and IFoo.multiadapt() are nice, neither is as
 simple as saying:

You don't? I do write IFoo(c1, c2) all the time!

Regards,
Stephan
-- 
Stephan Richter
CBU Physics  Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martijn Faassen wrote:
 Hey,
 
 My opinions:
 
 It'd be nice if getMultiAdapter's functionality was in reach without 
 typing: import zope.component; zope.component.getMultiAdapter. The 
 IFoo() single adapter lookup shows us a way to make this possible: a 
 method (in this case __call__ on the interface). It does bother me on 
 occasion that I need to invoke multi adaptation in such an entirely 
 different way. I must also note that it's a very common intuition to 
 want to do something like IFoo((a, b)).
 
 Even though  my intuition is usually like Jim's and prefer to have two 
 different methods, given different semantics, I consider the differences 
   in semantics here such a grey area I'm on the fence.
 
 That the object itself is returned if it already provides the interface 
 in single adaptation is a difference in semantics,

The fact that the object may be returened as its own adapter is
logically opaque to the caller, who should properly care only that the
returned value implements the interface.  For exactly the same reason, I
think that calling an iterface with an *empty* context list could
reasonablly be construed as a 'getUtility' request:  the fact that a
factory is called for one, and not the other, is irrelevant *to the caller*.

 but since there's 
 just no possibility of doing so in the case of multi adaptation anyway, 
 you can argue whether this is a difference in semantics or not, just 
 some semantics that doesn't apply. __conform__ is a bigger difference, 
 but given that polymorphism abounds in object oriented code, having 
 different behavior with different inputs is not *that* surprising either.

Exactly.

 Anyway, if we want to split methods, I'm fine with a properly named 
 method for multi-adaptation on the interface. For completeness' sake 
 you'd also want a properly named method on the interface for 
 single-adaptation.
 
 IFoo.adapt() for normal adaptation
 IFoo.multiadapt() for multi adaptation

I'd rather have 'adapt' take *args for the contexts, and keywords for
extras (like name).

 sound reasonable to me. We then explain that if you call IFoo directly, 
 IFoo.adapt is called. These could then also be extended to support named 
 adapter lookup and such.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+wHp+gerLs4ltQ4RAkyiAJ0biniCdvVIs5vgVCzSm1ISzbWF5QCfQ7FQ
iQsVQ0u8q1ZWg2UEGOx43qY=
=HlvT
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Sep 26, 2007, at 3:37 PM, Dieter Maurer wrote:
 
 Jim Fulton wrote at 2007-9-26 15:10 -0400:
 ...
 Jim Fulton wrote at 2007-9-26 11:29 -0400:
 ...
 IFoo(x)
 IBar(multi=(x,y))
 Actually, that is not the case.  If x already provides IFoo,  
 then in
 the first case, the existing object is retuned. Nothing is
 instantiated.  OTOH, in:

   getMultiAdapter([x], IFoo)

 or
   getAdapter(x, IFoo)

 either there is an error or some factory will be called.  x  
 won't be
 returned unless the factory happens to return it.
 Is this not an irrelevant implementation detail?
 No, the specified behavior is different.
 Hm. But getAdapter and getMultiAdapter may return x as well
 (when the factory decides to do this).

 Thus, why is it relevant?
 
 Because they don't take into account what x already provides.  They  
 will always call some factory.   Also, they never call __conforms__.

Why does the caller care?  She just wants an object which will provide
the 'IFoo' contract on behalf of the passed context.  If 'x' is capable
of providing 'IFoo' without help, then failing (or worse, returning a
less-specific factory result) when calling 'getAdapter' is the Wrong
Thing (a least surprise violation, if nothing else).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG+wLR+gerLs4ltQ4RAuojAJ90QTKCzaEonLYPTqmJ+5SJpz1eDwCgyy4K
w59LMYo7ur+GCfEwAy+w5aM=
=Weg9
-END PGP SIGNATURE-
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Brandon Craig Rhodes
Tres Seaver [EMAIL PROTECTED] writes:

 Martijn Faassen wrote:

 IFoo.adapt() for normal adaptation
 IFoo.multiadapt() for multi adaptation

 I'd rather have 'adapt' take *args for the contexts, and keywords
 for extras (like name).

And you could make the default= another possible extra!  In which
case our proposals at the moment compare something like this:

 Brandon
  Utility?  IFoo()
  Single adaptation IFoo(a)
  ... with default  IFoo(a, default=y)
  Multi adaptation  IFoo(multi=(a,b))
  ... with default  IFoo(multi=(a,b), default=y)
  Named multi adapter   IFoo(multi=(a,b), name='z')
  ... with default  IFoo(multi=(a,b), name='z', default=y)

 Martijn/Tres
  Utility   IFoo.adapt()
  Single adaptation IFoo.adapt(a)
  ... with default  IFoo.adapt(a, default=y)
  Multi adaptation  IFoo.adapt(a,b)
  ... with default  IFoo.adapt(a,b, default=y)
  Named multi adapter   IFoo.adapt(a,b, name='z')
  ... with default  IFoo.adapt(a,b, name='z', default=y)

Well, I have to admit, yours are a lot prettier.  The word adapt
takes no more characters than my multi, and parenthesis disappear!
And though I might quibble that adapt() would be better spelled
utility(), there is a nice symmetry about your idea.

 - Both patterns make it explicit to anyone reading the code when a
   default value is being passed, which should vastly reduce surprise.

 - Mine feels more natural and Pythonic to people who, like PvW in his
   book, think of adaptation as being like casting.

 - On the other hand, adaptation is *not* casting, and having to spell
   out adapt really makes for explicit code!  And the very natural
   handling of single or multiple *args in your scheme is very pretty.

 - My scheme requires the coder to remember that multi-adaption is
   done differently than normal adaption; yours does not.

 - My scheme, by requiring the magic keyword multi=, leaves the user
   in the same dratted danger as before - that he will call IFoo(a, b)
   and think that he's multiply adapting!

Given those last two points, I must abandon my earlier proposal and
respond to that of Martijn and Tres with:

+1

-- 
Brandon Craig Rhodes   [EMAIL PROTECTED]   http://rhodesmill.org/brandon
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: reasonable syntax for multi-adaptation

2007-09-26 Thread Marius Gedminas
On Wed, Sep 26, 2007 at 09:09:37PM -0400, Tres Seaver wrote:
 Why does the caller care?  She just wants an object which will provide
 the 'IFoo' contract on behalf of the passed context.  If 'x' is capable
 of providing 'IFoo' without help, then failing (or worse, returning a
 less-specific factory result) when calling 'getAdapter' is the Wrong
 Thing (a least surprise violation, if nothing else).

FWIW it was a big surprise to me when I discovered that IFoo(x) has
different semantics from getAdapter(x, IFoo).

Marius Gedminas
-- 
C is for Cookies.  Perl is even better for Cookies.


signature.asc
Description: Digital signature
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com