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 backwards
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
we want
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 the
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
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 care,
On Tue, Dec 1, 2009 at 14:21, Martijn Faassen faas...@startifact.com 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
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 adapters. We can
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 of
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 take
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
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 defined
Am 01.12.2009, 17:08 Uhr, schrieb Lennart Regebro rege...@gmail.com:
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.
On Tue, Dec 1, 2009 at 16:28, Martijn Faassen faas...@startifact.com 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
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 proposed
-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 utilities with
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,
and
it
16 matches
Mail list logo
