Re: An object-oriented network DBMS from relational DBMS point of view

Hi,
I do not agrre with the definition "instance of ADT" = object." nor do I think that object is not well defined.

Look up the book "Structure and Interpretation of Computer Programs" (SICP for short) by Ableson and Sussman.

The right name for "instance of type (or ADT)" is *value* and not *object*.

For example, lets look at the (abstract) type Rational with a (possible) represenation Rational [m, n] and the associated operations (artithmetic) and let's say implicit conversion semantics. A (possible) represenation of a value 2/3 is then Rational [2,3]. It will not change during programm execution.

Let's have a program segment:
....
v1 = Rational [2/3]
....
v2 = 1- Rational[1/3]
...

The variables v1 and v2 refer to the same value. Value has no identity. The variable has identy (name) and state (the value it currenty holds). All values (integer, real, relation ... ) have no identity.

This is te classical world of (imperative) programming which I persenally like. Simple, clean and well defined. No pointers needed. Variables changes values via ssignement. Values themselve are invaraint.

On the other hand, I don't think that object is (so) vague defined. Its definition includes identity and state that can be changed (like a classical typed variable from the above example).

A typical "object type" = class would be Account with a (possible) representation Account [no, balance] and the operations withdraw and deposit. A (possible) *current* represenation of an account is then Account [38324234, 1000]. Notice that this ID 38324234 makes all the difference.

Let's have a program segment:
....
o1 = Account [38324234, 1000].
....
o2 = withdraw (Account [38324234, 1000], 50) ...

The variables o1 and o2 are almost not needed. In esence they are just pointers (here we go ... ) to the objects which have identity by themselves. After the evaluation of withdraw the "object has changed" and variable o2 just points to the changed object. It is now represented as Account [38324234, 950].

This is another world of programming. To me it's much more complex and I have to see what we have gained with it. It is important to ntoce that we have inheritance, polymorphisam, data encapsulation etc. with a proper defined type system (values + variables). What brings object/classes to the picture ..... I don't know.

So, IMO object/class is well defined.

But, in the region of RM I prefer the term entity instead of object as Chen has thought us. Entities have also identity (inside a particular entity type) and they are trivially mapped to Relations. So I prefer to think about the Account as an Entity and handle persistance via RDBMS. No classes/objects needed. In the programming part of the application use a well mapped type system (same types in the program as in the Relation attributes) hence no mismatch.

Greetings from Croatia,
Drago

P.S.: I personally differentiate between code and data. To me data is like mass in physics. It is static and has structure. I move it around, destroy it etc. Code is like Newton or Einstein's equations. They can change and still act on the same "stuff" and show the same behaviour in a prticular domain. They bring dynamic to the system.

"Daniel Parker" <danielaparker_at_gmail.com> wrote in message news:1173887130.484521.142470_at_p15g2000hsd.googlegroups.com...
> On Mar 14, 9:15 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

>>
>> The word "object" is essentially meaningless. It has no clear definition
>> and gets used to mean a variety of things. Those who use it frequently
>> do so to impede communication.- Hide quoted text -
>>

>