On Wed, Nov 25, 2009 at 16:41, Martijn Faassen 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:
>
> @IFoo.implements
> class
Chris McDonough wrote:
> Martijn Faassen wrote:
[snip]
>> So now that we've had some discussion and to exit the "bikeshed" phase,
>> let's see about getting some volunteers to work on this.
>>
>> The goal here is to make interfaces disappear into the language as much
>> as possible.
>
> I sugges
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Martijn Faassen wrote:
>
>> Are people okay with the proposed semantics?
>
> +1.
>
>> Would people be okay with such an upgrade path? Any better ideas?
>
> I would start issuign DeprecationWarnings (yes, I know I'm their
Adam GROSZER wrote:
> I had a feeling that adapter lookup can be alone slowish with lots of
> registrations.
> We had a large project that was cut in half and the z3c.form UI, which
> is rather heavily adaptation based got a boost after that.
Interesting. It'd be interesting to do some experiments
Chris McDonough wrote:
[snip]
> It tries to address the following problem.
>
> Currently people seem to get wrapped around the axle and confused by the
> purpose of "the ZCA", which currently implies at least two different things:
>
> - Machinery to perform complex registrations and lookups usin
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
Summary of messages to the zope-tests list.
Period Fri Nov 27 12:00:00 2009 UTC to Sat Nov 28 12:00:00 2009 UTC.
There were 6 messages: 6 from Zope Tests.
Tests passed OK
---
Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Fri Nov 27 20:38:38 EST 2009
URL: http://
On Sat, Nov 28, 2009 at 12:14 PM, Martijn Faassen
wrote:
> Adam GROSZER wrote:
>> I had a feeling that adapter lookup can be alone slowish with lots of
>> registrations.
>> We had a large project that was cut in half and the z3c.form UI, which
>> is rather heavily adaptation based got a boost afte
Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers :
> Well, I don't think the difference between adapters and utilities is
> important, but I can understand why some people find calling the
> interface odd: it is when you think about it objectively.
I have to agree with this. IFoo(myobject) is not
Charlie Clark wrote:
> Am 27.11.2009, 15:57 Uhr, schrieb Chris Withers :
>
>> Well, I don't think the difference between adapters and utilities is
>> important, but I can understand why some people find calling the
>> interface odd: it is when you think about it objectively.
>
> I have to agree w
Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough :
> We've been handling some constructive criticisms from repoze.bfg
> developers
> with respect to verbosity resulting from use of unnamed utility
> registrations
> in a component architecture registry.
> These criticisms, and our amelioration
Am 28.11.2009, 16:06 Uhr, schrieb Martijn Faassen :
>> I have to agree with this. IFoo(myobject) is not intuitive. I know it
>> used
>> a lot because it's convenient shorthand but I've never read anywhere
>> that
>> interface classes are, in fact, callables. We certainly don't normally
>> trea
On Sat, Nov 28, 2009 at 16:39, Charlie Clark
wrote:
> So adapters are reduced to type conversion?
That's what adapters are. They aren't reduced to it, it's what they
do. They adapt one object with one interface to have another
interface. That can indeed be seen as a type conversion.
> Thanks for
Lennart Regebro wrote:
>> I have very much
>> come to appreciate the power of this delegation in, say, BrowserViews;
>> even if it did take me several months to understand the multiadapter
>> pattern!
>
> I hear this a lot, so this is apparently something that is common to
> take a while to grasp.
Martijn Faassen wrote:
> Chris McDonough wrote:
>> Martijn Faassen wrote:
> [snip]
>>> So now that we've had some discussion and to exit the "bikeshed" phase,
>>> let's see about getting some volunteers to work on this.
>>>
>>> The goal here is to make interfaces disappear into the language as muc
Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro :
> That's what adapters are. They aren't reduced to it, it's what they
> do. They adapt one object with one interface to have another
> interface. That can indeed be seen as a type conversion.
I agree that that is probably the most common use for
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()
Charlie Clark wrote:
> Am 24.11.2009, 04:24 Uhr, schrieb Chris McDonough :
>
>> We've been handling some constructive criticisms from repoze.bfg
>> developers
>> with respect to verbosity resulting from use of unnamed utility
>> registrations
>> in a component architecture registry.
>> These c
On Sat, Nov 28, 2009 at 17:35, Charlie Clark
wrote:
> Am 28.11.2009, 16:55 Uhr, schrieb Lennart Regebro :
>
>> That's what adapters are. They aren't reduced to it, it's what they
>> do. They adapt one object with one interface to have another
>> interface. That can indeed be seen as a type convers
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
> I
20 matches
Mail list logo
