[Zope3-dev] Re: Persistent module notes and proposal

[Tres Seaver]

Leonardo Rochael Almeida wrote:
> At Mon, 05 Jan 2004 18:09:16 -0500, Jim Fulton wrote:
> 
> 
>>Casey Duncan wrote:
>>
>>>On Mon, 05 Jan 2004 16:36:24 -0500
>>>Jim Fulton <jim at zope.com> wrote:
>>>[...]
>>>
>>>
>>>>If you wanted to share a list that way, you'd need to make it a
>>>>persistent list.
>>>>
>>>>I'm inclined to disallow import of non-persistent objects from
>>>>persistent modules.
>>>
>>>
>>>I agree. So classes and functions in persistent modules are persistent
>>>automagically?
>>
>>Yes.  There's a mapping step that happens after module execution in
>>which we map regular classes, functions, and interfaces to persistent
>>ones, updating existing values as appropriate to make imported refernces
>>do the right thing.
> 
> 
> What if we do it the other way around, and treat module globals as
> explicitly volatile?
> 
> PM globals wouldn't survive a server restart nor a PM edit, as editing the
> module would imply a module reload.
> 
> I think this matches more closely the behaviour of fs modules, which we
> are already used to. This might make PMs less useful, but their semantic
> will be more easily defined and their implementation a little bit easier,
> I think. This achieves the goal of reflecting the module state solely by
> their source, and even allows PM global mutables to be used for volatile
> registries, just like fs modules.

+1, as you have just expressed the notion which has been struggling to 
the surface of my mind as I have mulled over this thres.  I think the 
*only* persistent attribute of the PM should be the source itself;  all 
else would a "cooked" cache.

This is somewhat like the "PythonLibrary" notion which Evan Simpson has 
been kicking around for Python2.

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com