Re: Object-relational impedence

Marshall wrote:

> On Mar 5, 12:19 pm, rugby fan <q..._at_q.com> wrote:

SP>But you cannot claim that all OO prog langs will have an implementation SP>that forces the fallacious "one at a time" scheme

M>Can you name one that doesn't? (I think I agree that M>one could exist in theory, however.)

>>CLOS, OCaml etc (by virtue of being built on Functional prog langs) .

> Well, hrmm. Let's see. While those are certainly *interesting*
> and *surprising* examples (in this context) I don't know that
> they qualify as counterexamples to my point.

> Take CLOS. It is an object system built on LISP. As such, is
> it fair to consider it in terms of the primitives or "axioms" that
> LISP is built on?

[ stuff snipped - but read and acknowledged - it helped to clarify

   the point you have wanted to put across. ]

> Many good things can be said of this pattern, but it is not set-oriented.

> I am not familiar enough with OCaml to say much. But
> if we were talking SML, (a language I have the utmost
> respect for) I would still not consider it set-oriented.
> map(), filter(), fold(), while providing collection-oriented
> interfaces, are typically not primitive in the language.

OK.
You regard "X-oriented" as something for which the facilities to support X are provided at a fundamental level (like arithmetic ops, CAR/CDR in Lisp etc) and not built (by whoever) from the fundamental constructs of a prog lang.

Fair enough.

M>Why are you bringing up functional programming when M>talking about OOPLs?

>>Because FP has :

>>- been able to support OO quite easily

>>- has an interesting execution infrastructure that IMHO makes it a >> good candidate for supporting the Relational paradigm

> Hrmmm, well, I have to admit you make a good argument here.
> (Although you must grant me that, we people speak of OOPLs,
> they are not usually thinking CLOS!)

I would not call it an "argument" as such. More thinking out loud about candidate technologies for resolving the impedence problem (conceptually and performance-wise) .

> But I am, rather, speaking of what languages' axiomatic natures are.
> I could, in fact, write a Relation class in Java, and provide set-
> oriented
> methods for it, and a whole host of relational goodness. But that
> wouldn't make Java a relational language per se.

> Virtually no languages have primitive support for anything like a
> collection. SQL and SETL and a few others; that's it. There are
> some languages that were designed from the start with *list*
> processing in mind: lisp (and I should probably also mention the
> APL family here.) There are some *very* interesting things
> in there, but not things I would say could be strictly described
> as set-oriented.

I take a slightly different view in that I obviously have the need for various collection types, and support for a Relational "calculus" to use on those collections. I also need support for collections of ADTs in particular.

If possible I would like the prog lang user to be able to construct specific collections such as sets etc, and for the prog lang env to be within reasonable performance of something that is designed for the support of some one specific aspect (as Lisp is for lists etc) .

I think that FP is the paradigm that could possibly do this.

Regards,
Steven Perryman Received on Thu Mar 06 2008 - 18:27:44 CET