Martijn Faassen wrote:
> Chris McDonough wrote:
>> Personally I think that it's a fantasy to believe that the difference
>> between
>> an object created via a factory on-demand and an object simply returned
>> should
>> *never* matter to a caller. You may not want the caller to need to care,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
> Hi there,
>
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or "lookup()" on
> instance. It unifies utili
Gary Poster wrote:
> You are leaving out the variants of 3 and 4 that allow calling the
> interface to support multiadaptation, but do not unify utilities.
True, my mistake. Lennart pointed that out too just now.
> My impression is that I am not the only one who is not pleased with
> the propose
On Tue, Dec 1, 2009 at 16:28, Martijn Faassen wrote:
> * abstract factory not called on an object ("utility factory",
> "null-adaptation")
>
> In: the requested interface
>
> Process: look up factory. Call factory.
>
> Out: a new instance that provides the requested interface
When would
Am 01.12.2009, 17:08 Uhr, schrieb Lennart Regebro :
> I'm +1 for 5.
"wot he said" x 10 :-)
The video + audio to scart example struck me last night and providing
expressive(?) examples of this to match so that one is less easily caught
by tuples as arguments is a doddle.
cables = (audio, vid
Hey,
Chris McDonough wrote:
[snip]
> If you want to create a world where callers never need to care about the
> lifetime of any object returned by a component lookup, you could also return
> a
> proxy wrapper around the returned object that only allows for the invocation
> of
> the methods de
Chris McDonough wrote:
> I am more or less somewhere between -0 and +0
That is a high degree of precision. Maybe we need to start thinking of
our voting system as a Decimal instead of an int?
Martin
--
Author of `Professional Plone Development`, a book for developers who
want to work with Plo
Chris McDonough wrote:
> Personally I think that it's a fantasy to believe that the difference between
> an object created via a factory on-demand and an object simply returned
> should
> *never* matter to a caller. You may not want the caller to need to care, and
> it may be inconvenient to t
Martijn Faassen wrote:
> First a statement about the goal of this discussion. The goal of this
> discussion is to convince people to unify the lookup API. I wouldn't
> want to make lookup API improvements depend on improvements to
> zope.component inspired by the discussion below. I'm in favor
On Dec 1, 2009, at 8:21 AM, Martijn Faassen wrote:
> Hi there,
>
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or "lookup()" on
> instance. It unifies utilities with adapter
On Tue, Dec 1, 2009 at 14:21, Martijn Faassen wrote:
> Hi there,
>
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or "lookup()" on
> instance. It unifies utilities with adapters.
Chris McDonough wrote:
> On the semantics of the change:
>
> Personally I think that it's a fantasy to believe that the difference between
> an object created via a factory on-demand and an object simply returned
> should
> *never* matter to a caller. You may not want the caller to need to car
Martin Aspeli wrote:
> Can you summarise what you mean by this? The thread is so long...
[snip]
> My brain hurts... examples?
[snip]
> I'm afraid you've lost me. Four ways sounds bad, though. ;-)
I've edited down and clarified what I posted earlier.
First a statement about the goal of this discu
On Dec 1, 2009, at 9:54 AM, Chris McDonough wrote:
> Martijn Faassen wrote:
>>
...
> I am also in favor of unifying adapter and utility lookup. Or at least
> creating a more normalized API.
I guess it is no surprise that I am in favor of a normalized API but against
the unification.
> On
Martijn Faassen wrote:
> Hi there,
>
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or "lookup()" on
> instance. It unifies utilities with adapters. We can make it do whatever
Martijn Faassen wrote:
> Hi there,
Thanks for doing the summarise-and-move-it-on job so well, Martijn. It's
really important.
> I'd like to summarize the options I've seen appear in the discussion so far.
>
> We have the following options:
>
> 1) introduce a new method, such as "instance()" or
Hi there,
I'd like to summarize the options I've seen appear in the discussion so far.
We have the following options:
1) introduce a new method, such as "instance()" or "lookup()" on
instance. It unifies utilities with adapters. We can make it do whatever
we want without worrying about backwar
17 matches
Mail list logo
