On Thu, Dec 03, 2009 at 07:44:54AM +0100, Christian Theune wrote:
That reminds me that I had the occasional wish to invoke the ZCA using
some kind of chaining mechanism so that an adapter can ask for the next
less specific adapter that would have been invoked if the former wasn't
there. The
On 11/30/2009 10:05 AM, Brian Sutherland wrote:
On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seavertsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for it will
On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for it will short circuit, leading you into
infinite
On Nov 30, 2009, at 4:05 AM, Brian Sutherland wrote:
On Wed, Nov 25, 2009 at 10:17:41PM +0100, Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for
Tim Hoffman wrote:
Just re-inforcing this I almost never do IFoo. adaption as I am almost
always using
multiadapters and utilities so I completely forget about the IFoo
adaption capability.
Which means I always just write getAdapter as well as it seems more
consistent to
from an api
On Wed, Nov 25, 2009 at 16:41, Martijn Faassen faas...@startifact.com wrote:
As a final thought, I don't like having to import 'implements' from
zope.interface either. Since we're moving to Python 2.6 which supports
class decorators, I'd like to see something like this become possible:
Chris McDonough wrote:
Martijn Faassen wrote:
Hey,
Christian Theune wrote:
[snip]
Another option would be to provide a backwards-compatibility mode of our
code which can be switched on and off.
Your notion of bringing the component lookup mechanics closer to being a
language feature is
Martijn Faassen wrote:
I'd be in favor of an API based off calling the interface directly for
everything *if* we can come up with a backwards compatibility story somehow.
Just as a data point, I forgot to hook adapter_hook in BFG (and I still
haven't), which means that the IFoo() sugar
Just re-inforcing this I almost never do IFoo. adaption as I am almost
always using
multiadapters and utilities so I completely forget about the IFoo
adaption capability.
Which means I always just write getAdapter as well as it seems more
consistent to
from an api consumption point of view.
T
Am Mittwoch 25 November 2009 17:54:53 schrieb Chris McDonough:
Gary Poster wrote:
FWIW, I'm saying that utilities and adapters are different. I share
your/Martijn's/other people's general thoughts about merging adapters and
multiadapters in the interface __call__ syntax.
There might
Hanno Schlichting wrote:
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for it will short circuit, leading you into
infinite recursion. Except that it doesn't:
[snip
Hey,
Christian Theune wrote:
[snip]
Another option would be to provide a backwards-compatibility mode of our
code which can be switched on and off.
Your notion of bringing the component lookup mechanics closer to being a
language feature is very intriguing and I like it a lot. However, if
On Thu, Nov 26, 2009 at 11:09:35AM -0500, Benji York wrote:
On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote:
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
I know it's probably a spurious
Martijn Faassen wrote:
Hey,
Christian Theune wrote:
[snip]
Another option would be to provide a backwards-compatibility mode of our
code which can be switched on and off.
Your notion of bringing the component lookup mechanics closer to being a
language feature is very intriguing and I
Thomas Lotze wrote:
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The
Wolfgang Schnerring wrote:
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I quite like the simplicity of this spelling, so I want to be sure
*why* it
Martijn Faassen wrote:
Thomas Lotze wrote:
You didn't explicitly mention the subject of backwards compatibility in
your original message, so let's make it explicit now: Is backwards
compatibility a goal in this discussion?
True. It's indeed a goal, as I'd like to be able to use this sooner
Martijn Faassen wrote:
But someone needs to think of a feasible upgrade scenario. We could
instrument all calls to IFoo and see whether a default argument is in
use, but what then? I'd be hard to distinguish a default argument from
one we're meant to adapt. I'd also be non-trivial to scan
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
matt...@matthewwilkes.co.uk wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above, but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a spurious
On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote:
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
matt...@matthewwilkes.co.uk wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above, but
throwing it out there anyway:
On Thu, Nov 26, 2009 at 9:04 AM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
On Thu, Nov 26, 2009 at 14:34, Benji York be...@zope.com wrote:
On Wed, Nov 25, 2009 at 11:17 AM, Matthew Wilkes
I know it's probably a spurious use case, but what if I want to adapt a
tuple?
There could be
Shane Hathaway wrote:
[I talk about backwards compatibility issues with some proposed API changes,
but this modification doesn't have this issue]
Here is an interface decorator I intend to try out soon. It adds
convenient component lookup methods to a particular interface without
requiring
Thomas Lotze wrote:
[snip]
Then let me suggest not changing the call signature of an interface at all
but only add one or a few new methods. Firstly, this will keep backwards
compatibility even with code that adapts a tuple, and secondly, it allows
us to implement a simple and consistent API
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
Then let me suggest not changing the call signature of an interface at all
but only add one or a few new methods. Firstly, this will keep backwards
compatibility even with code that adapts a tuple, and secondly, it
allows us to implement a
On 11/25/2009 08:51 PM, Fabio Tranchitella wrote:
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
I'm probably saying something very
On 11/26/2009 10:48 AM, Martijn Faassen wrote:
Thomas Lotze wrote:
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I like the interface being called to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christian Theune wrote:
On 11/25/2009 08:51 PM, Fabio Tranchitella wrote:
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support
Hi there,
Reading the thread Chris McDonough started (and ended) about modifying
the way utility registration works reminded me of the following
thinking. It's quite independent and probably even antithetical to
Chris's approach as it uses interfaces, but that's fine.
The goal is to make it
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen
faas...@startifact.com wrote:
[snip good stuff]
Multiadapter:
IFoo.multi(x, y)
I'm not sure I like the following suggestion better than the above, but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
Multiadapter with default:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a spurious use case, but what if I want to adapt
a tuple?
Matt
On Nov 25, 2009, at 10:41 AM, Martijn Faassen wrote:
...
Thoughts?
FWIW, this mirrors some of the thoughts I've had, after a lot of discussions
with Launchpad/Canonical engineers about the pros and cons of the Zope
interface and component code. My OSCON presentation touched on some of these
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and consistent API for all components including
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I seem to remember there had been some discussion at some point about
dropping
On Nov 25, 2009, at 11:34 AM, Thomas Lotze wrote:
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I seem to remember there
Gary Poster wrote:
FWIW, I'm saying that utilities and adapters are different. I share
your/Martijn's/other people's general thoughts about merging adapters and
multiadapters in the interface __call__ syntax.
There might should be more obvious APIs for just *retrieving* an adapter based
On Nov 25, 2009, at 11:54 AM, Chris McDonough wrote:
Gary Poster wrote:
FWIW, I'm saying that utilities and adapters are different. I share
your/Martijn's/other people's general thoughts about merging adapters and
multiadapters in the interface __call__ syntax.
There might should be
Chris McDonough wrote:
There might should be more obvious APIs for just *retrieving* an adapter
based
on a set of interfaces; it's useful to be able to retrieve an adapter without
invoking it. Currently this is possible via registry.adapters.loookup, which
is fine.
And I know it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Benji York wrote:
On Wed, Nov 25, 2009 at 10:41 AM, Martijn Faassen
faas...@startifact.com wrote:
[snip good stuff]
Multiadapter:
IFoo.multi(x, y)
I'm not sure I like the following suggestion better than the above, but
throwing it out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Wilkes wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but
throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a spurious use case,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gary Poster wrote:
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility()
[or possibly IFoo() instead?]
What about a simple and
* 2009-11-25 19:35, Tres Seaver wrote:
IFoo()
IFoo(x)
IFoo(x, y)
You can't use an arbitrary number of positional arguments for the
contexts, because we need to support the named / default cases too.
I'm probably saying something very stupid... What's wrong with the it?
Can't we define
On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote:
Matthew Wilkes wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but throwing it out there anyway:
Multiadapter:
IFoo((x,y))
I know it's probably a
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
This also doesn't allow you to use this (anti?)pattern:
class Foo:
implements(IFoo)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Sutherland wrote:
On Wed, Nov 25, 2009 at 05:17:17PM +0100, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
This also doesn't
On Wed, Nov 25, 2009 at 9:52 PM, Tres Seaver tsea...@palladion.com wrote:
Hmm, I may be missing something here, but if Foo implements IFoo, then
the getAdapter lookup for it will short circuit, leading you into
infinite recursion. Except that it doesn't:
[snip example]
which strikes me as
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument is the default.
Regards,
Martijn
Marius Gedminas mar...@gedmin.as writes:
On Wed, Nov 25, 2009 at 01:29:25PM -0500, Tres Seaver wrote:
Matthew Wilkes wrote:
On 2009-11-25, at 1601, Benji York wrote:
I'm not sure I like the following suggestion better than the above,
but throwing it out there anyway:
Multiadapter:
Hi all
Betreff: Re: [Zope-dev] improving the utility and adapter lookup APIs
On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
Martijn Faassen wrote:
Adapter:
IFoo(x)
[...]
Multiadapter:
IFoo.multi(x, y)
[...]
Utility:
IFoo.utility
Martijn Faassen wrote:
Thomas Lotze wrote:
[snip]
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
The last one won't work if we want to maintain backwards compatibility.
The second argument is the
* On Nov 25, 2009, at 11:17 AM, Thomas Lotze wrote:
What about a simple and consistent API for all components including
utilities, adapters and multiadapters:
IFoo()
IFoo(x)
IFoo(x, y)
I quite like the simplicity of this spelling, so I want to be sure
*why* it must be ruled out.
51 matches
Mail list logo
