home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / database / informix / 1872 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.5 KB
  1. Path: sparky!uunet!gossip.pyramid.com!pyramid!infmx!news
  2. From: cortesi@informix.com (David Cortesi)
  3. Newsgroups: comp.databases.informix
  4. Subject: Re: Heading toward 4GL++
  5. Message-ID: <1992Sep3.194121.1122@informix.com>
  6. Date: 3 Sep 92 19:41:21 GMT
  7. References: <1992Sep2.174618.3753@bjudev.UUCP>
  8. Sender: news@informix.com (Usenet News)
  9. Reply-To: cortesi@informix.com
  10. Organization: Informix Software, Inc.
  11. Lines: 45
  12.  
  13. In article <1992Sep2.174618.3753@bjudev.UUCP> mfox@bjudev.UUCP (Mike Fox)  
  14. writes:
  15. > I would like to structure the code in development so that the transition to
  16. > Informix 4GL++ is as smooth as possible.  Does anyone have an idea what 
  17. > Informix is planning to do in this area?
  18.  
  19. Quite a bit was said about future directions for 4GL at the Informix
  20. User Conference in July. Working within the bounds of what was said
  21. there, it would be fair to say that 4GL is going to be enhanced into
  22. a very sound, very conventional, object-oriented programming language.
  23.  
  24. For example, if you know Pascal and can follow how Apple migrated that
  25. language smoothly into Object Pascal, you have the concept (not
  26. to say the feature sets are the same; they are not).
  27.  
  28. But you can pick up any of the 100's of books about OO design
  29. and OO programming and start reading, because sound design for *any*
  30. OO language will also be sound design practice for 4GL.
  31.  
  32. It is said that you can "do" OOP in any language, even
  33. assembler.  So in fact you can start designing 4GL apps
  34. using OOD techniques right now. There is a definite
  35. "object-oriented frame of mind" that you need to acquire
  36. in order to exploit this technology, but you don't have to
  37. wait for 4GL to begin getting into that frame of mind.
  38.  
  39. > For example we could at the present time conceive of an "object" as 
  40. >  
  41. >           a module of code  ----|
  42. >           a table  -------------|--   together, an object
  43. >           a form   -------------|
  44. > 
  45. > I know this isn't strictly an object since any table cannot be bound to a
  46. > certain piece of code. Nevertheless it does begin to imitate an object in
  47. > that it has an entity (table) and its behavior (code). The so-called objects
  48. > would be reusable among programs. 
  49.  
  50. You have the general notions, or at least the buzzwords, so you have
  51. begun reading the right books.  You might want to think less in terms
  52. of "modules" of code and more in terms of functions. A "behavior"
  53. is a function; a "module" is a convenient grouping of source lines but
  54. is not a good design unit.
  55.  
  56. I can say from experience that the more practice you get in applying
  57. the techniques of "abstraction" and "encapsulation," the better.
  58.