home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!decwrl!cache.crc.ricoh.com!cache!steve
- From: steve@crc.ricoh.COM (Stephen R. Savitzky)
- Newsgroups: comp.object
- Subject: Re: Three approaches to designing OBJECTs
- Message-ID: <STEVE.93Jan22110628@styx.crc.ricoh.COM>
- Date: 22 Jan 93 19:06:28 GMT
- References: <1993Jan21.191431.11321@uhura1.uucp>
- Sender: news@crc.ricoh.com (USENET News System)
- Followup-To: comp.object
- Organization: RICOH California Research Center
- Lines: 19
- In-Reply-To: rdm@uhura1.uucp's message of Thu, 21 Jan 1993 19:14:31 GMT
- Nntp-Posting-Host: styx.crc.ricoh.com
-
- I recommend a variation on your approach 1.
-
- Give Entity a virtual function (I usually call it dscr()) that returns
- a descriptor for the entity, having as one of its attributes a list of
- attribute-name / attribute-descriptor pairs. If you're really lucky,
- you can get this information out of the OODB's schema. Otherwise, you
- could be ambitious and get them by parsing the declarations yourself.
-
- Note that the descriptors are not persistent -- they're just static
- data structures referred to by the dscr() function. Because they're
- not stored with the object, they can have application-specific stuff
- in them, like how to display the attribute and where it goes on a
- panel.
-
- You can do a lot with a descriptor of this sort, including the generic
- Get, Set, and display stuff you mention, and also generic stream I/O
- (<< and >> operators). Put a class name in the Entity descriptor, and
- you can use it in error messages. You can also do run-time class
- checking.
- --
- \ --Steve Savitzky-- \ 343 Leigh Ave \ REAL HACKERS USE AN AXE!
- \ steve@crc.ricoh.COM \ San Jose, CA 95128 \ Free Cyberia!
- \ w: 415-496-5710 \ h:408-294-6492 \
- \_________________________________________________________________________
-