Container __get/set/delitem__? (was Re: [Zope3-dev] naming issues: id vs name, delObject vs ?)

[Casey Duncan]

On Wednesday 15 May 2002 09:59 am, Tres Seaver wrote:
> because it doesn't assume "folder is just like dictionary";  instead, i=
t
> leverages the component architecture, so that an adapter for "expensive=
"
> containers could be written which "lazified" the 'items' and 'values'
> calls.

But, if all folderish somethings supported the mapping interface in the f=
irst=20
place, the adapter is unecessary. Now granted, you could still use an ada=
pter=20
for objects that want to be simple and only support a bare-bones mapping=20
interface.

I disagree that making something hard to write (or longer, or more delibe=
rate)=20
correlates to thinking about scalability more.

If we make it necessary to use an adapter, just to access items in a cont=
ainer=20
consistently (or "pythonically" if you will), what is it that we are gain=
ing?=20
A consistent abstraction from an inconsistency that we could avoid in the=
=20
first place?=20

> > e.g. (perhaps -- but it's late and I'm tired ;), "del obj['usr']" rm'=
s
> > your /usr directory.

BTW: del obj['usr'] would remove my usr object, which might look conspici=
ously=20
like a directory in a filesystem, but is in fact in no way like one at al=
l.

I think you have uncovered the basic problem with metaphors. You can only=
=20
carry them so far before they break down. Like dragging the floppy disk i=
nto=20
the trash on a Mac to eject it.

I have begun to dislike OFS to a certain degree, because mapping things t=
o a=20
filesystem can stymie your thinking. And mapping data structures=20
hierarchically is not always the best way. But, I have already tooted tha=
t=20
horn elsewhere.

-Casey