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

[John Landahl]

[catching up after a few days]

On Friday 09 July 2004 08:08 am, Phillip J. Eby wrote:
> >Lisp is >40 years old, but isn't CLOS itself only about 20 years old?
>
> Okay, so I exaggerated for dramatic effect.  :)

Even so, it does speak to the constant gripe of Lisp people that many problems 
they solved years ago are constantly being "re-solved" in newer languages.

> What are your use cases for nested contexts?

I don't have any personally, but it seems to come up from time to time.  The 
Modeling documentation mentions a few use cases, usually related to complex 
user interactions, iirc.

> >peak.model: ...
>
> Primarily, I'm thinking about changes to the persistence mechanism,
> internal attribute representation machinery, event/validation machinery,

I'd like to hear more about your event/validation machinery ideas when you get 
a chance.

> and maybe the "method exporter" subsystem of peak.model.  I'm not really
> looking at changing the surface APIs, which I'd like to disturb as little
> as possible.

Ok, great.

> So, if you're just defining metadata or methods you might not even notice
> that anything's changing.  But if you're doing certain kinds of validation
> hooks or digging deep into the feature framework, there might be some
> changes.

In the past I only went as deep as cycling through .mdl_features as a generic 
way to handle model object metadata.

> It's possible we'll also make use of "method combining".  That "Practical
> Lisp" chapter discusses it briefly, but I haven't addressed it in my posts
> much.  The idea is that for some generic functions, you don't want to just
> pick the "most specific" method, but rather you want some combination of
> the return values from all the cases that apply.  For example, the total of
> the return values, a list of the return values, a boolean "and" of the
> return values, etc.

I had meant to ask you about this originally, in fact.  It's one of the more 
interesting features of CLOS.

> The dispatch system I've written allows this, in a manner as flexible as
> CLOS, although I don't have any of the convenience features actually
> written.  You just pass a "method combining" function in when you initially
> create the generic function ...

Excellent.  This sounds very powerful.

> >peak.metamodels: With peak.metamodels I'm primarily interested on
> > XMI-based code generation capabilities. ...
> Sadly, I don't have the bandwidth right now to pursue any improvements to
> it without funding.  I'd like to put this in a separate distribution of
> some kind, because I don't want to keep lots of unfinished experimental
> things in mainline PEAK.  So, IMO, it's got to "grow or go".
> ...
> On the bright side, generic functions make code generation and almost any
> other type of AST/model/tree processing easier, so you may find that you
> can do what you need with what's already there, once generic functions have
> landed.  Heck, if you can contribute some code-generation-from-UML stuff to
> complement the existing generation-from-MOF, maybe I could simply consider
> peak.metamodels "finished", and therefore keep it in the primary distro. 
> :)

I think it's an important capability to have, so I'll look into it at some 
point after I've gotten the hang of the generic function framework.