home *** CD-ROM | disk | FTP | other *** search
/ ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng) / ProfitPress-MegaCDROM2.B6I / PROG / UTILITY / OBRONM11.ZIP / README.OE < prev    next >
Encoding:
Text File  |  1991-02-24  |  6.4 KB  |  145 lines
  1.  
  2. Oberon-M Example  
  3.  
  4. (c) Copyright E. R. Videki 1991
  5.             
  6.  
  7. There have been many people asking for a rich, comprehensive
  8. example of how the Oberon programming language's new features
  9. can be used.  In particular, "type extension" and "object
  10. oriented features" are the most requested topics.
  11.  
  12. The files which accompany this text is such an example.  It
  13. is not intended to be the only way to use such features, but
  14. it was written to clearly show how Oberon's type extension
  15. features and the key "object oriented language" features
  16. can be used.
  17.  
  18. The source was written to run under my MSDOS based
  19. Oberon-M(tm) compiler, using one of the library modules supplied
  20. there (Term.Mod).  However, if you look at the comments
  21. in the application's I/O module and the "main" module (named,
  22. respectively, OEIO.Mod and OE.Mod) you will see that with
  23. a text editor and about five minutes of time you can convert
  24. the application to run under ETH Zurich's closed-environment
  25. Oberon System.
  26.  
  27. In other words, this application was written with the purpose
  28. of showing Oberon features by example, and although it shows
  29. off Oberon-M well, those persons who don't have an MSDOS 
  30. machine can still execute it under the ETH Oberon System
  31. to further delve into programming in this language.
  32.  
  33.  
  34. APPLICATION OVERVIEW
  35.  
  36. The application framed by these Oberon modules is a simple
  37. name- and phone number-database handler.  The names are
  38. maintained on a binary tree structure in memory.  The 
  39. phone numbers are handled similarly, but on their own tree.
  40. Thus, searches performed either looking for a known name
  41. or a known phone number can be made easily.  Elements of
  42. one tree can point to elements on another tree, so that 
  43. names and phone numbers are cross-linked to each other.
  44.  
  45. The implementation of the handling of names and phone
  46. numbers is simplistic, but turned out to work pleasingly.
  47. If you wish to expand the capabilities of this application
  48. some suggestions would be to have the name (and name searches)
  49. be more clever than just having a simple string of characters.
  50. Similarly, the phone number is just a string of characters.
  51. Both could be made to permit humans to specify names
  52. and numbers with spaces within the strings, and still match on
  53. search patterns, or perhaps to permit wildcard characters
  54. within search patterns.
  55.  
  56. The functions provided by the application include adding 
  57. a name (and optional phone number) to the databases, 
  58. searching by a known name, searching by a known phone number,
  59. and displaying all nodes on both the name and phone trees.
  60.  
  61.  
  62. MODULE ORGANIZATION
  63.  
  64. All modules of the application are prefixed with the letters
  65. "OE", standing for "Oberon Example."  As mentioned above,
  66. by changing a very few lines (about 6) in two modules you can
  67. convert the application to run within the Oberon System's
  68. self-contained environment instead of Oberon-M's MSDOS
  69. environment (modules OE.Mod and OEIO.Mod).
  70.  
  71. The modules are described below, with notes about the 
  72. important things they illustrate as part of this example.
  73.  
  74.  
  75. OE.Mod    - The so-called "main" module of the application,
  76. this module has the user-visible commands that can be 
  77. executed.  This module shows several things.  First,
  78. the name and phone trees are separate trees, and each node
  79. of these trees have differing record types. This module
  80. shows how multiple extended types are simultaneously 
  81. handled.  This module is also the highest level client of
  82. all exported types and procedures, so illustrates the way
  83. they must be referenced by common routines.  Finally, this
  84. module shows how each tree node is assumed to have an
  85. object specific (oriented) "method" handler that is responsible
  86. for doing things directed at any given node.  Thus, this
  87. main module doesn't need to know exactly how to display
  88. a name or a phone number, nor really even know how the data
  89. is organized on a tree node, but simply invokes the object
  90. handler to take care of such details.  This makes it very
  91. flexible to change the internal organization or structure
  92. of either the name or the phone tree nodes without changing
  93. anything in this top level module.  In the past, such a
  94. thing typically would be impossible -- the method handler
  95. thus ties the way to do things with a node, to that node,
  96. instead of to the client source.  
  97.  
  98. OETree.Mod - This module handles binary trees -- of any kind.
  99. It is independent of the application, and shows the way that
  100. an Oberon module can handle tree node insertion and searches
  101. without having any idea what the actual application is.  The
  102. data type defined here, a record called an "Apple" (hanging
  103. from the tree), is the base type that the application builds
  104. its name and phone structures upon.  The Apple node contains
  105. tree links that are invisible to clients (the tree structure
  106. is handled exclusively by this module), plus a reference
  107. field (pointer to another node) which can be used any way 
  108. the application wants.  Additionally, the node's "method" or
  109. "command" handler is defined as a procedural type in the
  110. Apple record, but again the application can define what
  111. actions are appropriate to the tree types it defines.
  112.  
  113. OENames.Mod - This module takes the Apple defined in 
  114. the OETree.Mod module, and extends it to contain the record
  115. fields it needs to handle names entered into the database.  
  116. Additionally, this module contains the method handler which
  117. knows the structure of the name data, and when the correct
  118. command is directed to it, it will display the name.  Also,
  119. this module contains the special search procedure, passed
  120. to the tree-traversing routines in OETree.Mod, which 
  121. tells OETree.Mod how the names are organized (in this way
  122. it is up to the application to define what the tree ordering 
  123. is, instead of being fixed in place by the tree handler, 
  124. OETree.Mod).
  125.  
  126. For this simple example, the names are alphabetized using the 
  127. underlying machine's character code sequence (eg: ASCII).
  128.  
  129. OEPhone.Mod - This module handles the telephone number tree.
  130. It is very similar to OENames.Mod, except that it handles
  131. a different kind of type extension based upon OETree's 
  132. basic Apple node.  
  133.  
  134. OEIO.Mod - This performs string reads and writes to the 
  135. human being.   This module makes the application independent
  136. of what kind of system it is running on.  
  137.  
  138.  
  139.  
  140.             -- E. R. Videki
  141.             erv @ k2.everest.tandem.com
  142.             
  143.             19 April 1991
  144.  
  145.