[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Tres Seaver wrote:
> [snip]
>>> The second problem that might arise, is that the implicit assumption 
>>> that every object inside Zope 2 inherits from Acquisition base 
>>> classes no longer holds. Code that relies on the various aq_* 
>>> attributes to be there need to be adjusted to use the Acquisition 
>>> methods instead.
>>
>> The major downside here is that restricted code doesn't have access to
>> the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
>> hence use the attributes.  ('aq_base' should not be allowewd at all, as
>> it strips away security context).
>>
>> There are probably thousands (or even tens of thousands) of templates
>> and scripts "in the wild" which use these attributes.  I don't think we
>> can break them in a single release:  we need to deprecate them first
>> (with suitalbe logging output), and maybe even provide
>> '__parent__'-aware workarounds / fallbacks in their implementations.
> 
> I'm trying to understand what is proposed that would break them. All 
> existing content objects will continue to use acquisition. Only things 
> like Five views will stop using acquisition and switch to a __parent__ 
> pointer. I doubt there are that many scripts that rely on getting a 
> .aq_parent, say, on a Five view. There will be view code that relies on 
> this, so I imagine we expect that should be rewritten to use the 
> functions instead, but not scripts.

You're right, and Tres acknowledged that in a follow-up post already :). 
What's more, views actually *do* have those aq_* attributes for BBB, so 
even those scripts that do view.aq_parent will continue to work no 
problem. See my answer to Tres's post.

> If we were to change OFS so that it'd start using __parent__ then I can 
> see where you're coming from, but I don't think anyone's proposing that?

Nope. And it would be quite an involved thing to do, because currently 
Zope 2 objects have no persistent reference to their parent whatsoever 
(in fact, parent i.e. cyclic references used to be unsupported by early 
ZODB versions). So basically, if you wanted to introduce __parent__ 
pointers to existing Zope 2 objects, you'd have to traverse the whole 
object tree and set them based on their acquisition parent. I *suppose* 
this could be done ad-hoc (when you first traverse over an object that 
doesn't yet have its __parent__ pointer set), but I'd rather not think 
this through right now.

So, like I said, it's not on my list, and I bet it won't be for a long 
time. Mostly because a) it's probably unnecessary and b) much code in 
fact relies on content being of the type Acquisition.Implicit... 
<dtml-var standard_dtml_header> anyone? :)