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

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> 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!

I think this nails our point of difference.

It seem to me that you're taking basically any sound development practice
and calling it "OO".  I find that odd, since most of it predates what we
know as OO chronologically, but at least it seems you're not claiming that
OO polymorphism, inheritance and encapsulation are the be-all and end all
of modeling and design.  This is a good thing.

Note that you can do what I did above in languages that don't even claim
to be OO.  In LISP (not even CLOS), you do it with lambdas.  In C you do
it with function pointers.  Both predate OO, so I don't see how you can
say they are "emulating" OO.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python