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

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

Jeff,

From what I can gather the following is the kernel of your message:

> If we could, as a practice, declare a data model as a separate entity, along
> with constraints that can easily be expressed declaratively, along with a
> type system that supports inheritance, along with default and constant
> values... **then** hang methods off of those types, along with other
> processing methods not related to direct data model manipulation, wouldn't
> we make our lives a whole lot simpler? I mean, creating a transform from one
> declared schema to another would certainly be simpler, wouldn't it?

And I quite agree (I think most hereabouts would agree to some extent).

Abstract data types were about bundling data into neat packets for clean
functions (preferably unit functions) to operate on.

OO was about making the operations actually intrinsic to the bundles of
data.

The post-OO evolution at which I think you hinted is about flipping it
all the way around so we're drafting neat functions to operate against
the properly considered data models.

Data maintenance is a more important and more risky task than code
maintenance.  A trememdous side-effect of XML adoption is that it's
encouraging developers to finally start putting these matters in the
right order.

BTW, I think one of XP's most valuable lessons is that it's not just OK
but a valuable exercise to willingly throw away code.  The important thing
is to be far more careful with data.


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