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

[Paul Moore]

Interesting article. I've been following PEAK for some time now, but
never fully understanding how I might use it. I think that this
article has clarified some of the reasons for that, as well as
confirming that I really like the ideas behind PEAK, and the direction
it is going in - if  only I could get my head round how to apply it
:-)

"Phillip J. Eby" <pje at telecommunity.com> writes:

> Part of this long-term vision included an MDA, or Model-Driven
> Architecture, based on UML and other OMG technologies.  You can see
> this influence as far back as the earliest days of the TransWarp
> frameworks, and as far forward as the current peak.metamodels and
> peak.storage.xmi packages.

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.

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.

> These observations have helped me to realize that there are different
> "persistence styles", with corresponding scopes of applicability for
> the use of domain models.  I have dubbed them "fact base", "persistent
> root", and "document", where "document" persistence can be thought of
> as a specialized form of "persistent root" persistence.
[...]
> a mechanism that's at its best only for the document style -- as
> PEAK's is.

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

> Currently, PEAK's DM system attempts to support all of the styles, and
> thus ends up really only being *good* at the "document" model.  This
> is well-illustrated by the fact that the only implemented DM's in PEAK
> that are not just tests or examples are document-based: the XMI DM in
> peak.storage.xmi, and the HTMLDocument DM in peak.ddt!  The only
> drawback to PEAK DM's in the "document" and "persistent root" models
> is that DM's require a special key to indicate the root object.  Apart
> from this, they work quite well.

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.

> I'm speaking here of "multiple dispatch".  More specifically, I'm
> talking about a kind of symmetric multi-dispatch that's closer in
> nature to the kind found in the Cecil and Dylan programming languages
> than what's in CLOS, but the basic idea is the same.

Now *this* really excited me. I have been reading up a little on
multiple dispatch (the Nice language - nice.sf.net - uses it, and has
some good examples) and it looks like a very powerful and readable
approach. The example in the Nice tutorial of using multiple dispatch
in place of the Visitor pattern is a good example.

>      [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...?

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

> You may be wondering what the catch to all this is, or perhaps you've
> already made up your mind as to what that catch *must* be.  You're
> maybe thinking it must be hellishly slow to eval() all those strings.
> Or maybe that it's all a pipe dream that will take ages to implement.
>
> But actually, no, neither one is the case, as you might already know
> if you've been paying close attention to recent PyProtocols checkins.
> The new, experimental 'protocols.dispatch' module on the CVS trunk has
> already proven that it's possible to implement highly efficient
> generic functions in Python, complete with predicate dispatch.  They
> don't yet have the nice API I've presented in this article, but they
> do exist, and their execution speed in typical cases can actually
> approach that of the PyProtocols 'adapt()' function!

Woo hoo. Not only a nice idea, but available now? Off to look at
PyProtocols CVS...

> So, here's your chance to change history.  (Or at least a HISTORY.txt
> file or two!)  Tell me, what am I missing?  What am I doing wrong?
> Ask me questions, tell me this is crazy, or whatever you want.  Your
> feedback (including questions) about this plan is respectfully
> requested, and will be greatly appreciated.

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.

I'll remain neutral on the higher level stuff like the query language
and the data management API. As I say, I don't have the background to
comment properly. But from an "amateur" point of view, your ideas look
good.

It sounds like there are exciting times ahead!

Paul
-- 
The only reason some people get lost in thought is because it's
unfamiliar territory -- Paul Fix