home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / object / 3199 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.0 KB
  1. Xref: sparky comp.object:3199 comp.lang.eiffel:1062
  2. Newsgroups: comp.object,comp.lang.eiffel
  3. Path: sparky!uunet!gatech!cc.gatech.edu!news
  4. From: guna@cc.gatech.edu (L. Gunaseelan)
  5. Subject: Re: Persistence: Pragmatic and Abstract
  6. Message-ID: <1992Aug13.163917.1771@cc.gatech.edu>
  7. Keywords: persistence think class oop
  8. Sender: news@cc.gatech.edu
  9. Organization: College of Computing, Georgia Tech
  10. References: <1992Aug9.164259.23429@reed.edu>
  11. Date: Thu, 13 Aug 1992 16:39:17 GMT
  12. Lines: 48
  13.  
  14. In article <1992Aug9.164259.23429@reed.edu> chaffee@reed.edu (Alex Chaffee) writes:
  15. >I have an object-oriented design question. This is my first big OOP project,
  16. >and I'm fumbling through it the best I can. The project involves two
  17. >programs, a client and a server, and they need to send data structures back
  18. >and forth across a local network. To accomplish this, I imagine that each
  19. >data structure will be an object that can "wrap itself up" into a stream of
  20. >bytes (actually into a Macintosh handle), and then "unwrap" such a handle
  21. >and change its state to match the other object's. These handles will be sent
  22. >across the wire and "unwrapped" at the other end.  In other words, the
  23. >problem is one of persistence.
  24. >
  25. >What's the problem? Since I'm using the Think Class Library, I have a class
  26. >hierarchy available to me which implements things like arrays, which I want
  27. >to use. Unfortunately, this hierarchy doesn't allow persistence. I am left
  28. >with several options, and I can't decide between them.
  29. >
  30.  
  31. The point I am making here may not be of direct use to solve
  32. your problem. However, I would like to highlight that the problem is
  33. one of language design than programming. 
  34.  
  35. In C language, when you see a pointer you are not sure of what
  36. it points to (with typecasting and so on); when you have list
  37. you don't know how long it is, it requires traversing the list and
  38. packing the elements. The XDR (external data representation) support
  39. that is part of the Sun RPC (also OSF/DCE, I guess) allows the 
  40. programmer to do exactly that.
  41.  
  42. In contrast, consider the Eiffel programming language. In Eiffel,
  43. there are no pointers and it uniformly uses reference semantics - 
  44. a reference always points to an object of specific type.
  45. Since objects are completely typed,  the language design
  46. allows writing routines that can automatically pack and unpack
  47. objects, without out bothering the programmer to write class-specific
  48. marshalling and unmarshalling routines. This is the basis of the 
  49. STORABLE class in the Eiffel implementation. 
  50.  
  51. In fact, we have a distributed implementation of Eiffel that runs
  52. on the Clouds distributed operating system, where any graph structure
  53. of fine-grained Eiffel objects can be passed during remote
  54. invocations (RPCs) by deep copying the graph into a string of bytes. 
  55. The programmer makes RPC calls as he would in a procedural language, 
  56. and the run-time system handles marshalling and unmarshalling 
  57. automatically, using the routines available in the ISE's run-time
  58. library.  Again, the programmer never needs to write class-specific
  59. packing/unpacking routines.
  60.  
  61. Guna..
  62.