[Zope3-dev] Re: proposed changes to contained helper functions

[Garrett Smith]

Philipp von Weitershausen wrote:

> Fred L. Drake, Jr. wrote:
  >> The container ideas are really founded on the mapping interface, so I
>> suspect the DOM should avoid __name__, and only implement __parent__
>> as a read-only property that returns self.parentNode.
> 
> 
> That's how the DOM implementation in my sandbox does it right now (if 
> only I could get all the tests pass ;)).
> I have so far implemented my own machinery to deal with parenting; it's 
> not much since it only covers the cases I need for DOM. I would really 
> like to see some kind of general parenthood machinery in Zope3, though. 
> As I said earlier this thread: as a subset of the container ideas...
> 
>   * parenthood + mapping interface = container ideas
> 
>   * parenthood + index interface = DOM, music charts hitlist, etc.
> 
>   * ...
> 
> Smells like a proposal, eh?

I'm not sure containment is necessarily bound to mapping concepts. The 
intent of setContained is to be a general purpose 
parenting/event-generating function. It seems the short-fall is its use 
of names.

The current 'setitem' implementation handles the following (I use 
'parent' for container and 'object' for contained):

1. Checks the integrity of name (must be non-None, unicodable, 
non-duplicate)

2. Performs a lookup on the parent to see if the object is already 
contained under the given name - if so, setitem is a no-op

3. Possibly alters the object stored by adding a marker interface 
(IContained) or wrapping it with a proxy (ContainedProxy)

4. Sets the parent and name info for the object

5. Updates the underlying data structure to contain the object

6. Generates/publishes either an added or moved event, depending on 
whether or not the object originally had a parent

7. Publishes a modified event for the parent

Without names, each step is as follows (I think...working this out as I go):

1. No need to check the type of name - step doesn't apply

2. The function would have to lookup the object using something like a 
__contains__ method using the object rather than the name

3. This step would remain unaltered

4. The child's name would be None

5. The 'set' function would be called with the object as the sole argument

6. This step would remain unaltered

7. This step would remain unaltered

With this in mind, we could add a new function:

   def setNamelessContained(parent, setf, containsf, object):
     ...

which would implement steps 1 to 7 for nameless containment (detailed 
code omitted for brevity/laziness).

I can understand the thinking to treat this case as 'parenting' rather 
than 'containment', but I think containment is a generic enough concept 
to work for non-mapping relationships.

On a slightly different note, what would you think of alternate 
spellings of these related functions:

   def setitem(container, object, name, setitemf=None):
      """If setitemf is None, uses container.__setitem__"""

   def setContained(parent, object, name, getf, setf):
     """getf must conform to getf(name)
     setf must conform to setf(name, object)"""

   def setNamelessContained(parent, object, containsf, setf)
     """containsf must conform to containsf(object)
     setf must conform to setf(object)"""

The intent here is to make these functions as similar in use as 
possible. In most cases, developers will use setitem. In cases where 
developers are dealing with a parent that is not a container, the last 
two functions will be used - named containment would use setContained, 
nameless setNamelessContained.

Thoughts?

  -- Garrett