Re: OO fans bashing Joins

From: Kyle Lahnakoski <kyle_at_arcavia.com>
Date: 2000/03/17
Message-ID: <38D229C0.EC88671A_at_arcavia.com>#1/1


> Which niche? I agree that it has it's place, but that place is
> not everywhere.

OO and the languages that are "OO" are two very different things. Considering just C++ or Java they have half ass implementations, making OO a hard paradigm to use in procedural/relational programming. Pure OO implementation is almost implemented in Small Talk. Scheme may be a pure implementation, if you consider lists as objects, but I do not know the language well enough. My current area of research is to fix this OO implementation issue so that it is applicable to all areas; we may all speculate about my success.

> Do you have any examples of how it (allegedly) improves upon
> procedural/relational programming?

Relational programming is improved by removing explicit 1-1 joins. The people table and the customer table could have 1-1 relation when a person (name, address) is a customer (club_member, total_purchases) . OO helps make a customer appear seamlesly as a person; e.g: has a name.

One of my current questions is: "Do all 1-1 relations imply membership to the same object?". I can not think of a counter example. When you think you have one I can give a response. But I bet my answer will involve a concept similar to wave-particle duality.

Procedural programming also benefits. Functions are objects too! It is a severe short coming of many OO languages that do not implement this. Everyone can agree upon the power of the C function pointer. I program in Java much, and that power is not available to me. Technically it can be done, but the application is no longer OO, it is a mess: many static methods, and complex method extraction using the reflect API. Functions as objects allows the OO implementation to have the power of C function pointers.

I have considered the Add_Two_Integers instruction. It is an object by itself. Some programmers may make this a member of Integer, but then where would Add_an_Integer_and_a_Float go? Either Integer or Float is arbitrary. Keeping these types of instructions as separate objects realizes that addition is not the same concept as Integer or Float. People may question how to manage such a proliferation of 'many-to-many' function objects. That is where DB's come in. These functions are 1-1 with the elements of a matrix where the rows are the number types (Integer, Float, ...) and same with the columns.

	        |    Integer       |     Float       |    ......
        --------|------------------|-----------------|------
	Integer |   AddIntegers    | AddIntegerFloat |  
        --------|------------------|-----------------|------
	Float   |  AddFloatInteger |    AddFloats    |
        --------|------------------|-----------------|------
	......


-- 
----------------------------------------------------------------------
Kyle Lahnakoski                                  Arcavia Software Ltd.
(416) 892-7784                                 http://www.arcavia.com
Received on Fri Mar 17 2000 - 00:00:00 CET

Original text of this message