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

[Martijn Faassen]

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.

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?

Regards,

Martijn