[Persistence-sig] "Straw Baby" Persistence API
Kevin Jacobs
jacobs@penguin.theopalgroup.com
Tue, 23 Jul 2002 11:37:27 -0400 (EDT)
On Tue, 23 Jul 2002, Phillip J. Eby wrote:
> At 11:08 AM 7/23/02 -0400, Kevin Jacobs wrote:
> >On Tue, 23 Jul 2002, Jim Fulton wrote:
> > > Proxies can be a useful tool. We certainly use them a lot, although
> > > I sometimes feel dirty afterwards. ;) There are a *lot* of gotchas.
> > > I would definately *not* recommend using them for persistence. I
> > > would find a persistent mix-in to be far less intrusive than proxies.
> >
> >Believe it or not, but we're on the same wavelength:
> >
> >I'm thinking about proxy-methods a la aspect oriented programming, more than
> >whole proxy objects. e.g. cooperative __{g,s}et{attr,item}__ methods that
> >implement observer semantics and can forward to base-class methods. Whole
> >object proxies have the problem that object identity and type information is
> >obscured in ways that are contrary to standard Python idioms.
>
> So, you're saying you want to alter the types, then? The interesting part
> of that is how to alter them in such a way that your observing code doesn't
> get re-entered when you're modifying both subclasses and base classes of
> the objects. You'd need some kind of thread-specific collaboration stack,
> I think.
I suppose, though saying 'alter the types' implies slightly different things
to me. I don't see great difficulty in isolating subclass and superclass
modifications, although performance is clearly an important issue. As for
the thread-specific business, you've totally lost me. Can you provide a
use-case so that I can better understand where you are coming from?
Thanks,
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com