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

[Phillip J. Eby]

At 10:37 PM 7/7/04 +0200, Roché Compaan wrote:

> > First, they can be written all over the place. The two methods above could
> > live in completely different modules -- and almost certainly would.  Which
> > means that if you don't need, say, the pickle use case, you could just not
> > import that module, which means that branch of our "virtual if statement"
> > simply wouldn't exist, thus consuming no excess memory or CPU time.  So,
> > they can be "write anywhere, run any time".  Now that's what I call
> > "modular separation of concerns".  :)
>
>How is it determined that methods that live in different modules are
>implementations of the same generic function eg. there's a 'save_to'
>implementation in module X and one in module Y.
>
>Are all methods of a generic function bound to a module? It doesn't seem
>to make sense on class, or does it?

Oh, sorry, the original article didn't make that clear.  I've been wanting 
this for so long that I forget I haven't told everybody all my ideas of how 
they would work.  :)  Basically, they work like this:

from some_place import some_generic

[when("some(condition)")]
def some_generic(...):
     # new behavior here


The above code extends the generic function 'some_place.some_generic()' to 
add a method for 'some(condition)'.  So, the different modules implementing 
the hypothetical 'save_to' would do something like 'from peak.storage.api 
import save_to', and then "redefine" it locally.

In other words, generic functions are *mutable* objects, and "redefining" 
them actually extends them instead.  It's not unlike "property" methods in 
Visual Basic, or function/method signature overloading in C++ or Java.  In 
those languages, you can define a function or method with the same name 
more than once, it's just that there are qualifiers that let you 
distinguish variants.

However, since Python doesn't allow function or method names to be 
qualified (i.e. no dots), you have to import the function you want to 
extend into the current namespace first.  Then, just 'def' your new rule 
and its implementation.

Sorry I didn't make that clearer.


>Do you have more use cases in mind where methods live in different
>modules to prove beyond doubt how much one needs generic functions ;-)

 From my perspective, the really "killer apps" for generic functions are 
application-level "business" rules.  (I say "business" in quotes because 
games and other non-business applications often have lots of rule 
requirements as well.)

But, for PEAK itself, the killer app (or framework, rather) is obviously 
going to be object-relational mapping.