"Phillip J. Eby" wrote:
At 10:52 AM 3/6/01 -0500, Shane Hathaway wrote:
Perhaps... but as I see it, pickling the aspect weaving information into
each object makes it harder to vary the aspect weaving after objects
have been created.
That's not what I said. *Aspect objects* can be
At 10:52 AM 3/6/01 -0500, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
There's actually a simpler way. Aspect objects can be pickled as long as
all the objects in them can be pickled. Which means that as long as all
their methods are Zope objects, and all the nested classes are also
"Phillip J. Eby" wrote:
At 12:39 PM 3/2/01 -0500, Shane Hathaway wrote:
This could be achieved by generating a new Python module for each portal
instance, but that would mean sys.modules would have to be pre-loaded
with the information about each portal instance and that's not the ZODB
"Phillip J. Eby" wrote:
At 09:37 AM 3/1/01 -0500, Shane Hathaway wrote:
What is your vision of integrating AOP into a persistent object system?
Would one drop in an object that modifies the class loading mechanism so
that the classes come from a TW component rather than Python modules?
On Fri, 2 Mar 2001, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
One reason I've been racing like mad to get the preview release out is so
that, after seeing the usefulness of TW for the Zope 3 component
architecture, y'all might be interested in considering implementations for
module
At 03:53 PM 3/2/01 -0500, R. David Murray wrote:
On Fri, 2 Mar 2001, Shane Hathaway wrote:
"Phillip J. Eby" wrote:
One reason I've been racing like mad to get the preview release out is so
that, after seeing the usefulness of TW for the Zope 3 component
architecture, y'all might be
"Phillip J. Eby" wrote:
At 03:53 PM 3/2/01 -0500, R. David Murray wrote:
I could be wrong, but I didn't read what Phillip wrote as saying he was
suggesting TransWarp as a player in the Module Persistence implementation,
but rather that he wanted people to see the value of TransWarp first
At 12:39 PM 3/2/01 -0500, Shane Hathaway wrote:
We've been separating concerns in the PTK/CMF for the last year now.
We've been moving as many responsibilities of the content objects as
possible into per-portal "service" objects. The services provide user
interface, discussion capability,
This looks very interesting, Phillip. I haven't downloaded the package
yet, but I read the wiki and it finally made sense once I understood the
goal (I think): TW lets you set up the class inheritance hierarchy at
runtime. In normal OO methodology, you can only extend classes. With
TW, you can
At 09:37 AM 3/1/01 -0500, Shane Hathaway wrote:
This looks very interesting, Phillip. I haven't downloaded the package
yet, but I read the wiki and it finally made sense once I understood the
goal (I think): TW lets you set up the class inheritance hierarchy at
runtime. In normal OO
10 matches
Mail list logo
