[PEAK] Re: Persistence styles, MDA, AOP, PyProtocols, and PEAK

[Phillip J. Eby]

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
>day.

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
>something like
>
>       [when_types(Invoice,XMLDocument)]
>       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:

     [when((Invoice,XMLDocument))]

will probably be valid.  Failing that, you could use:

     from protocols.predicates import PositionalSignature as ps

     [when(ps(Invoice,XMLDocument))]

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
>PyProtocols CVS...

FWIW, there's a 'source-changes' mailing list you can use to keep up to 
date on what's going into CVS:

     http://www.eby-sarna.com/mailman/listinfo/source-changes

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 
argument/expression.)