-----BEGIN PGP SIGNED MESSAGE-----
Benji York wrote:
> Chris Withers wrote:
>> Benji York wrote:
>>> Chris Withers wrote:
>>>> I don't think it'll be a common pattern, but it doesn't feel right to
>>>> me that a named adapter (ie: one registered with a specific name) has
>>>> no way of finding out what name it has been registered with...
>>> Because the same adapter can be registered more than once, it would
>>> actually need to find out all the names with which it was registered.
>> Really? Now this is a use case I hadn't thought of.. can you give me
>> some examples of where you've run into this?
> I don't know that I have, but the component system doesn't preclude it
> so anything we come up with will have to take it into effect.
I have already used the same adapters registered under different names
(including the default "empty string" name). The CA is about allowing
component configuration to express policy, which sometimes means that
reusing an adapter makes sense (e.g., one might override the 'bar' named
adapter for a particular object, while leaving the 'foo' adapter alone;
the fact that the "default" registration uses the same factory for
'foo' and 'bar' Just Works now).
I would argue that having adapters which need to know their name is
*very* unusual, in fact.
>>> This seems somewhat analogous to a Python object being given multiple
>>> names. In that case too, there is no way for the object to know what
>>> it's names are.
>> Hmmm, okay, but I'd counter with both Zope 2 and Zope 3 having the
>> notion of an object knowing its own name. Certainly in Zope 2,
>> everything has an id or .getId(). That pattern evolved for a reason ;-)
> Sure, where "everything" is defined as content space objects, other
> objects more rarely.
That "pattern" has actually been the source of a lot of lost hair in the
past -- content itmes know their IDs, which means that renaming them
involves modifying *both* the container *and* the item. There was a
fishbowl proposal for Zope2 to move the ID into the acquisition wrapper,
which would have removed the need for content items to know them.
Tres Seaver +1 202-558-7113 [EMAIL PROTECTED]
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v220.127.116.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
Zope3-dev mailing list