Re: General semantics
Date: Fri, 21 May 2010 15:20:41 -0700 (PDT)
Message-ID: <661d6afd-14f6-40f5-a48b-e9a05f5f3304_at_l6g2000vbo.googlegroups.com>
On May 21, 10:06 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> Perhaps you are not communicating what you want to do. Creating OID
> because OOPLs have pointers sounds like a bad idea. Before going down
> that road, I suggest you ask yourself whether it is truly necessary and
> what you hope to achieve by simulating a low-level computational model
> in a higher-level symbolic algebra.
I would prefer to program in a pure relational model, but I must deal with both OOP classes and SQL tables, so I want to understand how the concepts and mechanisms fit together. As far as I know, relational theory has the expressive power to describe both. I can't change the fact that SQL tables allow duplicate rows (except via correct design, when I decide the design), but I can recognize rowids explicitly, and normalize tables and predict how they will join.
Similarly, I can't change the fact that OOP uses OIDs, but I can recognize them explicitly, understand why "new Integer(1) != new Integer(1)", and why and how a dictionary keyed on such objects works. In fact, I can use dictionaries to map objects to attributes based on their OID, a technique I recently used successfully in a visual control to avoid contaminating the objects in the data model with visual attributes. I also managed to consolidate my collection classes in that project to three generic classes: one for unary relations, one for binary relations, and one for sequences; it worked pretty well even though I couldn't use relational algebra in the language.
In the database for that project, I normalized beyond 3NF in some cases (not in all cases, which I now regret). The unary relation tables had a nice effect - CRUD became CRD, and since my sets of objects were equally normalized and corresponded to the table, loading and saving became an easy affair. Also, those tables which I normalized fully won't need to change as often as a denormalized table. I didn't need to design for significant scaling, but I had no performance problems at and over the projected level of use.
Analyzing OOP in relational terms simply opens the way to apply relational thinking in existing OOP systems. Received on Sat May 22 2010 - 00:20:41 CEST