Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dlogics!dsa From: dsa@dlogics.COM (David Angulo) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Summary: you missed the point Message-ID: <680@dlogics.COM> Date: 14 Nov 90 22:13:47 GMT References: <679@dlogics.COM> Distribution: comp Organization: Datalogics Inc., Chicago Lines: 24 In article , cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: | | I kind of see this as a cost/benefit problem. Implementing the system using | dynamic SQL would allow the system to grow more easily as new entities are | added to the system, but the startup cost would be more difficult than static | SQL to the individual tables. On the other hand, static SQL would make it | easy to write functions like Class::insert(), Class::modify(), etc. for each | entity (table) in the database, but, if you have a large number of tables, | you'd eventually have a significant maintainance problem on the repetitious | code when you need to make global changes (like changes in locking methods or | table history). Sort of a "pay me now or pay me later" scenario. If you just had to make a modify(), insert(), et. al. for each object, ther would be no problem. What I am talking about is having to make many of these methods for *EACH* class depending on how you need to access that class. For example, in Ed Berard's rectancle class, you need a Class::findall() to find all of the rectangles. You also need a Class::findMinimumSizeOf (size) to find all rectangles of a certain minimum size. You also need a Class::findSizeRange (lowerSizeBound, higherSizeBound), ad infinitum. -- 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