Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@f... +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
|
