[PEAK] Persistence styles, MDA, AOP, PyProtocols, and PEAK
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
> 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.
> 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
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