Re: Clean Object Class Design -- What is it?
Date: Sun, 2 Sep 2001 12:05:47 -0400
"Jim Melton" <Jim.Melton_at_Technologist.com> wrote in message
> Bob Badour wrote:
> > Using pointers, yes, I know that. We already know what a disaster it is
> > expose pointers to users. If you do not expose OID to users, how do
> > identify unique instances?
> See, I don't get your point. An OID is not a pointer. In the database
> use, an OID has a native representation (4 16-bit numbers) and a
> representation ( #dd-cc-pp-ss ). Neither of these are "pointers" any more
> a rowID is a pointer. Yet, because of the operator overloading in OO
> they can appear as a pointer to the programmer.
What bothers me about arguing over the issue of "pointers" in database systems is the assumption that pointers are somehow inherently evil. I disagree. In our applications, our most efficient data structures used for our most efficient algorithms use pointers (or references, if you're doing the Java thing).
The argument that pointers are dangerous to expose to "users" ... as in end-users ... is spurious, since I wouldn't expose an OID to an end-user anymore than I would expose them to the mechanics of an AVL tree. The real argument is whether we should expose pointers to *programmers* ... and that's a far different animal. Languages like Java and Ada have shown that you can expose pointers in a meaningful way and avoid the dangers of dangling references. IMO, OODBMSs accomplish the same purpose of providing the advantages of a pointer without the need for direct manipulation (I've never had a need to grab an OID and directly manipulate it). Received on Sun Sep 02 2001 - 18:05:47 CEST