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

[Garrett Smith]

Philipp von Weitershausen wrote:

> Garrett Smith wrote:
> 
>> Below are my proposed changes:
>>
>> 1. Add a new helper function 'containedObject'
>>
>>  def containedObject(object, parent, name=None):
> 
> 
> +1
> 
>> The class Foo in case 1 would be as follows:
>>
>>   class Foo:
>>       def __init__(self):
>>           self.bar = containedObject(Bar(), self, 'bar')
>>
>> 2. Add a new helper function 'setContained':
>>
>>  def setContained(parent, setf, getf, name, object):
> 
> 
> I like the idea. However, I have the feeling the name of the function 
> should somewhat reflect the fact that it's generating events. Also, 
> returning the result of containedObject() sounds like a good idea to me.

My intent is a function that's comparable to setitem, both in name 
convention and behavior. I'd be concerned about the name becoming too 
cumbersome. Any thoughts on a more appropriate name?

>> I agree with the decision to implement the container bookkeeping 
>> directly in container classes rather than through adapters -- it's 
>> much simpler and therefore less prone to error. However, I think the 
>> current implementation is a bit too inflexible. These proposed changes 
>> are an attempt to add enough flexibility without having to resort to 
>> adaptation.
> 
> 
> I agree.
> 
> I too have a small wish for the post-parendgeddon world of Zope3. In two 
> recent applications that I am porting over from ContextWrappers, one of 
> them being the zopeproducts.xml.dom package, I have realized that I 
> often need to express containment, or rather parenthood, however without 
> the naming part.
> 
> For example, a DOM node usually has a parent but it doesn't have a 
> specific name in that 'container' node. So, what I would like to see is 
> basically a subset of that container machinery (let's call it "parenting 
> machinery") or, rather, the container machinery being an extension of 
> the parenting machinery. That way adaptors defined at the parenting 
> level still work for objects at the container level.

It seems your application is a bit different from a typical __setitem__ 
scenario, where the child is named. Would something like this be more 
appropriate:

   def addContained(parent, addf, object)

I can hear Jim's "whoaaa" as I type this, but maybe some heightened 
crazy talk will get him into the discussion ;-)

  -- Garrett