[PEAK] Re: Persistence styles, MDA, AOP, PyProtocols, and
Phillip J. Eby
pje at telecommunity.com
Tue Jul 13 01:00:08 EDT 2004
At 08:15 PM 7/12/04 +0100, Paul Moore wrote:
>I think one of my fundamental problems with PEAK has always been that
>I have no background in MDA, UML, or similar techology. The
>terminology is strange to me, and the ideas don't fit my experience.
>So that the higher level aspects of PEAK have always eluded me.
That's okay; to a certain extent the point of my article is that over the
years we've moved away from MDA as a driving force. The truth is, it's
actually just as easy to write the peak.model classes by hand as it is to
draw them in a UML tool. Plus, I found that knowledge of UML wasn't as
widespread in the company as I thought. But I digress. :)
>On the other hand, I find the lower-level mechanisms, such as
>PyProtocols and the binding/config/naming features, extremely
>attractive, and aimed directly at the sort of issues (decoupling,
>flexibility, configurability) that I find a strong need for day to
Can I massage that it into a nice user quote? ;) I.e., something like:
"I find ... PyProtocols and the binding/config/naming features extremely
attractive, and aimed directly at the sort of issues (decoupling,
flexibility, configurability) that I find a strong need for day to day."
-- Paul Moore, PEAK early adopter
>And this is another piece of the puzzle for me. My background is in
>database admin - specifically Oracle - and a lot of my focus is on the
>types of model which you refer to as "fact base".
This is off topic, but tell me something... how *does* Oracle really get
away with making millions selling a product that can't even serialize
transactions without corrupting its own indexes? :)
>How would you view the DM used in the "Hello, world" sample from the
>Wiki? I found it quite non-intuitive, and I'm not sure if that was
>because I don't understand DMs well, or because the example was an
>inappropriate (or at least, strained) use of them.
No, it was appropriate, and it was responsible for a lot of my rethinking
regarding DMs. I was already having some doubts about them. The real
problem is that I've *never used DM's* in production, unless you count the
HTMLDocument DM in peak.ddt, and I don't think that that really qualifies.
The only thing I've actually used in production for DM-ish stuff is the
classes in ZPatterns... and really, it was Ty who used them more, but he
sat near me at Verio and so I obviously got "rapid feedback". :)
I *will* however, be using whatever replaces DM's, so you may be assured
that they will be a lot better than the current DM stuff. Essentially,
DM's were corrupted by early influence from Zope and ZODB, and my desire to
reuse their persistence mechanisms rather than using my own. The problem
is that those mechanisms are just plain wrong for the "fact base" model,
even though they can be abused to sort of fit, which is what ZPatterns and
PEAK DM's do. It's one of those things where, in the approximate words of
the Hitchhiker's Guide to the Galaxy, "the utter futility of the things is
masked by the sense of satisfaction you obtain from getting them to do
anything at all." :)
> > [when("isinstance(ob,Invoice) and isinstance(db,XMLDocument)")]
> > def save_to(ob,db):
> > # code to write out invoice as XML
>I'd like a shortcut form for this (likely very common) case - maybe
> def save_to(ob,db):
> # code to write out invoice as XML
>Depending on how "magical" the when form here is, this may be the sort
>of thing that a user extension can provide...?
Actually, 'when()' will accept anything that implements IDispatchPredicate
or ISignature. As it happens, that includes tuples, so:
will probably be valid. Failing that, you could use:
from protocols.predicates import PositionalSignature as ps
In any case, the actual syntax I'm implementing will also support:
[when("ob in Invoice and db in XMLDocument")]
for class tests, as this is easier to implement than matching 'isinstance'
in the parser/builder subsystem.
> > In addition to these very basic examples, expanding the approach to
> > support full "predicate dispatching", and to support CLOS-style
> > "method combining" and "qualifiers", would allow us to write things
> > like this "adventure game" example:
>I don't know how far you can (or intend to) take this, but I could see
>this being an *incredibly* powerful facility.
Yeah, the parser is done except for handling 'is', 'is not', 'in', and 'not
in'. That, and there's a bunch of tests to be done, the 'when()' decorator
to be written, and so on. But the current code in CVS already parses range
and equality tests just fine.
>Woo hoo. Not only a nice idea, but available now? Off to look at
FWIW, there's a 'source-changes' mailing list you can use to keep up to
date on what's going into CVS:
Some folks just browse the archives occasionally, or subscribe using digest
mode since sometimes I get a productive day (like yesterday) and post half
a dozen checkins. :)
>Most of my comments are above. But from my POV, the great thing about
>PEAK is the way it's built on highly generic and flexible base
>features. I see multiple dispatch as another example of this. I'd like
>to see the syntax for generic functions worked hard, until all of the
>awkward corner cases are sorted out. If necessary, it would be worth
>considering using an "interim" syntax, and lobbying for language
>support for a more ideal syntax if appropriate.
An important thing to realize about the dispatch language is that it will
look like Python, but it won't execute like Python. For one thing, stuff
may not happen in the same order as it would in plain Python, constant
subexpressions are aggressively folded and partially evaluated (including
variable and attribute lookups), and 'in' will have different
semantics. Even 'is' and 'is not' are going to be implemented differently
than normal, if you're doing 'is None' or 'is not None' tests. (They'll be
silently changed to the roughly-equivalent 'in NoneType' and 'not in
NoneType' tests, in order to speed up type dispatches on the same
More information about the PEAK