Re: OO versus RDB

From: Christian Brunschen <>
Date: Wed, 28 Jun 2006 15:28:59 +0000 (UTC)
Message-ID: <e7u77r$nq1$>

In article <>, erk <> wrote:
>topmind wrote:
>> [...] (Unlike OO, where encapsulation
>> encourages each object/class to reinvent its own
>> add/change/delete/cross-reference/search rules and interfaces so that
>> they are all different for each project or shop.
>Agreed. I wouldn't have a problem with inconsistencies if the languages
>just offered some powerful basic operations. You can't even write
>something in Java like this, which would be completely type-safe:
>Set<LineItem> items =

Perhaps somewhat interestingly, in a dynamic OO language such as Smalltalk, Objective-C or Ruby, you can use the technique of Higher-Order Messaging (HOM), as described in the 2005 OOPLSA paper <>, to do something quite similar; in Objective-C syntax something like

  NSSet *lineItems =
    [[[[order lineItems] selectWhere] status] equals:STATUS_SHIPPED];

>Instead, you write nested loops, or reflective methods with typecasting
>galore. With nothing similar to a relation, every distinct "query"
>result must have an object or interface, which leads to the sort of
>"load-it-all, save-it-all" code I typically see in O-O applications.

There are better approaches when using OO, even using languages such as Java. You might want to take a look at Apple's WebObjects, which incudes its 'Enterprise Object Foundation' (EOF) framework, which includes an object-relational modeler of sorts, though it actually has the developer model entities and relationships, and describe how they are represented in the OO and the RDBMS worlds, respectively.

>Ruby allows for much easier implementation of such code (and makes
>writing your own DSL easier), as does Python. Microsoft's .NET LINQ
>project is doing much better things.

You've seen the Higher-Order Messaging Extension to Ruby (HOMER) project? <>

>However, no O-O language I know of offers constraints of any kind, or
>basic relational operators like joins (Rails does some light lifting,
>but no heavy lifting.), so these languages are impressive primarily by
>comparison with the festering stagnation of Java/J2EE, which has
>replaced MS as the industry's greatest damper on genuine progress.

Agreed on J2EE.

>- erk

// Christian Brunschen> Received on Wed Jun 28 2006 - 17:28:59 CEST

Original text of this message