Re: Unknown SQL

>Bob> Object languages expose physical implementation details to
>Bob> programmers.
>>>
>>> Not the ones I have seen; most have some more abstract pointer model in
>>> which
>>> the pointers are certainly not bare addresses, and are more akin to
>>> primary/foreign keys.
>
>Bob> So, you are saying that all object languages use the same abstract
 pointer
>Bob> model
>
>Of course not.
>
>Bob> and can share OID's
>
>Possibly.
>
>Bob> and VTables?
>
>No, but I don't think this is job of the OODB; I am not interested in
 storing
>methods in an OODB; I just want the data. But OODBMS advocates may well
>argue that their product will take care of all this.

If you only store data in your network model OODB and not methods, how exactly does the OODB differ from a network model database?

>Bob> All support exactly the same set of redundant declarations (Array,
 Set,
>Bob> Bag, Collection) with exactly the same operators and performance
>Bob> characteristics? The common interface to the base object class is the
>Bob> same across all languages? All object languages support the same
 forms
>Bob> of inheritance? All object languages support polymorphism in exactly
>Bob> the same manner? All object languages have identical rules for which
>Bob> parameters pass by reference and which pass by value?
>
>No to all of the above

So, you admit that object languages expose physical implementation details to the user...?

>but you could adapt your 'persistent' objects to fit the OODBMSs
policies/capabilities (and hopefully there'll be some standard);

By "adapt to policies/capabilities" don't you mean adapt to the physical implementation details the OODBMS exposes to the user?

>that's pretty much what happens with the object layers that people create
>(manually or automatically) for RDBMSs.

Well, how one chooses to implement an application is independent of the DBMS. If the developers decide to turn a powerful functional, declarative DBMS into a navigational record processor, that's their problem.

>Bob> Which object languages have you used that leads you to the conclusion
 that
>Bob> they do not expose physical implementation details to programmers?
>
>Lisp and Java and CORBA. It is definitely possible to achieve reference
>semantics without becoming physical.

After all of the ways that I pointed out how object languages expose physical implementation details, that is all you have to say? If neither Lisp nor Java exposes physical implementation details, then I must assume that Lisp supports object references, always passes objects by reference, supports single inheritance of implementation and multiple inheritance of interface? After all, that's what Java exposes to the user.

>Bob> When it comes to OODBMS vendors supporting exactly the same
 programming
>Bob> language, they expose additional physical implementation details over
 and
>Bob> above those inherent in the language:
>
>yes, I agree, and that alone is enough to guarantee the lack of a OODBMS
>standard for years to come.

I go further. It guarantees that OODBMS will never even begin to approach the quality, functionality and performance of a relational database.

>Bob> The point is: When you identify data by uniquely identifying attribute
>Bob> values, you do not have to do anything to standardize. It is a priori
>Bob> unnecessary.
>
>yes, I agree, at the cost of a slight impedance mismatch (which I for one
 am
>perfectly happy with). I am still wondering whether the two models can be
>reconciled, because there are clearly similarities between references and
>keys.

Sure. You can overcome impedance mismatch by giving your object languages set-at-a-time operation, by giving them higher-level functional and declarative capabilities. This would make object languages rely less on navigation and iteration. It would also improve the languages immensely.

Cheers,
Bob Received on Sun Jul 22 2001 - 01:27:54 CEST