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 u
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
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
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
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
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=" a
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 fac
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 ext
-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, tha
-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
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 sayi
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
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
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
>>> instanti
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:
getM
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
> getAd
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
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 keywo
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 (especial
19 matches
Mail list logo
