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

[Roché Compaan]

* Phillip J. Eby <pje at telecommunity.com> [2004-07-07 08:49]:
> Preface
> -------
> 
> This is a rather long article, even for me.  (And that's saying 
> something!) 

One day when I grow up I want to write an article like this, well done
:-)

> Specifically, one defines a "generic function" that can have multiple 
> implementations (aka "methods").  The appropriate method to invoke is 
> selected at runtime using information about *all* of the function's 
> arguments, not just the first argument, as Python implicitly does for you.
> 
> What good does that do?  Well, think about storage.  Suppose you defined a 
> generic function like this:
> 
>     def save_to(ob, db):
>         ...
> 
> And what if you could define implementations of this function for different 
> combinations of object type and database type?  Maybe something like:
> 
>     [when("isinstance(ob,Invoice) and isinstance(db,XMLDocument)")]
>     def save_to(ob,db):
>         # code to write out invoice as XML
> 
>     [when("isinstance(db,PickleFile)")]
>     def save_to(ob,db):
>         # code to write out arbitrary object as a pickle
> 
> Doesn't this look a *lot* easier to you than writing DM classes?  It sure 
> does to me.
> 
> You might be wondering, however, how this is different from writing a bunch 
> of "if:" statements.  Well, an "if:" statement has to be written in *one 
> place*, and has the *same set of branches*, all the time.  But generic 
> functions' methods are different.
> 
> 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?

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

> I haven't narrowed these down 100%, but here's what I think so far.  The 
> query language is probably going to end up being Python, specifically list 
> or generator comprehensions, e.g.:
> 
>     [(invoice,invoice.customer) for invoice in Invoices if 
>     status=="pastdue"]

Beautiful.

-- 
Roché Compaan
Upfront Systems                 http://www.upfrontsystems.co.za