[PEAK] DM refactoring and asynchrony (was Re: PEAK and Twisted,
john at landahl.org
Mon Apr 19 15:30:15 EDT 2004
Phillip J. Eby wrote:
> The hard part of the design, that I'm chewing on in my spare time, is
> how to create a Pythonic FO notation, that won't end up looking like
> Prolog or Lisp!
Funny you should mention Prolog; I was thinking of it while reading your
description of FO concepts. A Prolog-ish notation might not be such a
> Indeed, the more I think about it the more I realize that trying to
> implement a lot of typical business functions by direct mapping to the
> OO paradigm actually *adds* complexity and effort.
I've been coming to this realization recently as well. I only recently
learned anything about Prolog, but it seems like there's a lot there
that could be applied to these kinds of problems. Have you looked at PyLog?
> This is both more and less granular than a DM. When you have related
> objects in two DMs, right now you must write code in both to save and
> load the linking attribute(s). The same thing in an FO approach would
> correspond to a single fact type, pairing the two objects. So, there
> would be only *one* implementation of that fact type, handling both
> sides of the relationship.
The "fun" part of this will be matching such relationships to underlying
data structures in a way which results in efficient SQL. One advantage
of the DM approach here is that you can write highly tuned SQL when
necessary because there's (often) a tight coupling between a DM and the
underlying data structures. (Ah, you mention this later on).
> Here, the idea is that a fact type such as 'order_total' is a protocol
> that you can adapt the editing context to. Thus, one would create
> different EC subclasses to define a specific schema mapping. The EC
> itself doesn't actually implement anything, however. Instead, you
> simply declare adapters (probably sticky ones) for the fact types that
> can be implemented in the schema. And if a compound fact type doesn't
> have a specific adaptation, it just creates a generic compound
> implementation over the adaptation of the fact types it comprises.
Where and how would you define the underlying schema?
More information about the PEAK