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

John Landahl john at landahl.org
Fri Jul 16 16:51:54 EDT 2004

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

More information about the PEAK mailing list