home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / modula2 / 1074 < prev    next >
Encoding:
Text File  |  1992-08-26  |  1.5 KB  |  34 lines
  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!usc!sol.ctr.columbia.edu!ira.uka.de!chx400!owf.ch!jw
  3. From: jw@owf.uu.ch (Juerg Wanner)
  4. Subject: Re: Oberon-2: Type Bound Proc question
  5. Message-ID: <1992Aug27.074023.6449@owf.uu.ch>
  6. Sender: news@owf.uu.ch
  7. Organization: OWF AG Zurich, Switzerland
  8. References: <9208240802.aa18279@thama1.apgea.army.mil> <1992Aug24.181819.6832@aero.org> <1992Aug25.124659.25394@titan.tsd.arlut.utexas.edu>
  9. Date: Thu, 27 Aug 1992 07:40:23 GMT
  10. Lines: 22
  11.  
  12. In article <1992Aug25.124659.25394@titan.tsd.arlut.utexas.edu> larry@tsd.arlut.utexas.edu (Larry Maturo) writes:
  13. >
  14. >I think I am finally able to understand what is going on.  You don't want to
  15. >pass an object by value since you could not change it's state, which makes no
  16. >sense since changing it's state is one of the primary things you do with an
  17. >object.  Espically since in Oberon-2 you can already mark fields as read only
  18. >so there should never be a case where you have a type bound procedure that
  19. >does not change an objects state.  This being the case the only way you can
  20. >pass it is as a pointer or a VAR parameter.
  21.  
  22. I think you get something wrong here. As a type-bound procedure has to be
  23. defined in the same module as the type it's bound to, it always has write
  24. access to all fields of that (record-)type (except of course the fields that
  25. are inherited from its supertype and that are not exported or exported as
  26. read-only). I also don't see why you don't want an object's method to be
  27. able to change the object?
  28.  
  29. Juerg Wanner    jw@owf.ch
  30. OWF AG
  31. Asylstr. 125
  32. 8032 Zuerich
  33. Switzerland
  34.