[PEAK] Persistence styles, MDA, AOP, PyProtocols, and PEAK
Phillip J. Eby
pje at telecommunity.com
Wed Jul 7 20:09:00 EDT 2004
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.
More information about the PEAK
mailing list