Re: Picking the Tools -- Marrying processing models to data models

["Al B. Snell" <alaric@alaric-snell.com>]

On Wed, 23 May 2001, Uche Ogbuji wrote:

> > Gimmee an example, I don't totally follow you...
> 
> Here's somthing in Python, a language, remember, that is basically OO but
> gives you plenty of escape hatches from OO when you need them.

I like Python. 

> class Customer:
>     #Basically a static class variable
>     emailMixin = UUCPEmailer()
[...]
> Customer.emailMixin = SMTPEmailer()

> And that's it.  We changed a core aspect of the system without needing to
> scrap the customer code.  No OO involved, just techniques familiar to
> any library.  We implemnented late binding through metaprogramming rather
> than inheritance polymorphism.  This sort of thing is a snap, and I do it
> quite often without needing inheritance or limited polymorphism, because
> my language of choice allows me to.

Ahah! Ok, in a non-OO language you'd normally have references to the UUCP
emailing function library in the Customer code, yes? Replacing those with
SMTP stuff would be tricky. Shoving stuff into classes is encouraged in OO
languages as a modularisation step, but the fact that the calls to the
UUCP library go through the vtable of emailMixin means that it's possible
to swap in another "library" without changing the source. Associating code
with data means that bits of code can be assigned to variables and, hence,
indirected.

In a non-OO language you could do the same thing by explicitly
creating a struct full of function pointers, but then you're just
emulating OO without language support!

> All very simple, really.  No great insights I offer.  Just a reminder that
> all of this is soup without One Methodology to Rule Them All.

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software