Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!psuvax1!wuarchive!cs.utexas.edu!uunet!dlogics!dsa From: dsa@dlogics.COM (David Angulo) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Summary: generic access methods are generatable Message-ID: <684@dlogics.COM> Date: 20 Nov 90 20:38:27 GMT References: <679@dlogics.COM> Distribution: comp Organization: Datalogics Inc., Chicago Lines: 47 In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: | >>>>> On 16 Nov 90 22:36:49 GMT, dsa@dlogics.COM (David Angulo) said: | | dsa> I don't see, however, how you could have these methods generated because | dsa> there's no way *I* can think of to figure out which "access philosophy" | dsa> (maybe SQL select criteria is a better term) you may want to use. There | dsa> are infinitely many ways you could want to access them. | | I think the C++ code associated with Class would be generatable, but I'm not | yet sure about the C++ code for ClassList. This is because the only access | methods I could see putting on Class are the primary key methods (select, | insert, delete, or update by primary key). I would agree with you as we have actually done this. Therefore your findAll(), nextAll(), and updateAll() are generated. But all of the other selection methods have to be coded by hand. This is usually MUCH more than the generated code. | All the information needed for | these methodologies should be in the data dictionary of the relational | database. The more I think about it, though, the more I believe that the | appropriate modelling methodology for a relational database from a series of | objects is to treat all access methods against the database as operations on a | list of some sort (even if its a list of one). I think I'm tending to agree with you here - still have to think about it more. | | Even in the case of list accesses, much of the information model should be | well understood at the time of writing the C++ code (and so generatable). For | instance, access methods against the primary or foreign key of a table. These | could be done with static SQL. All other methods would require dynamic SQL | which would need the names of the tables or columns involved (sound like | requirements for operations against the basic Classs?) for use in building the | proper SQL query. | Yes, but you really want to avoid dynamic SQL if at all possible. Anyway, if you use dynamic SQL, won't you really be giving control of the class's inner variables to the outside thus destroying your encapsulation??? This is what Ed was talking about from the beginning. -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473