home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / eiffel / 1316 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.2 KB  |  52 lines
  1. Newsgroups: comp.lang.eiffel
  2. Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
  3. From: sakkinen@jyu.fi (Markku Sakkinen)
  4. Subject: Re: Eiffel internals
  5. Message-ID: <1992Nov18.140905.23486@jyu.fi>
  6. Keywords: id of the caller..
  7. Organization: University of Jyvaskyla, Finland
  8. References: <Nov.17.18.57.56.1992.26484@paul.rutgers.edu>
  9. Date: Wed, 18 Nov 1992 14:09:05 GMT
  10. Lines: 40
  11.  
  12. In article <Nov.17.18.57.56.1992.26484@paul.rutgers.edu> partha@paul.rutgers.edu (nowhere_man) writes:
  13. >
  14. >I might need this for my work.Suppose class C declares x of class type
  15. >D, creates it and invokes x.m, where m is a method properly defined in
  16. >class D. Now is there any way to find out at the callee (ie in class
  17. >D) the (pointer to the) object of type C that calls the method m?
  18. > ...
  19.  
  20. Sorry, I am not actually helping you ...
  21.  
  22. This is not such a bad idea in principle.  At least I myself have
  23. sometimes thought that a facility for the supplier object to know
  24. the identity of its client could be useful at times.
  25. Somebody may even have suggested some mechanism for that in public
  26. (perhaps Mario Wolczko from Manchester University?).
  27.  
  28. An official client-identification facility would suit Eiffel
  29. particularly well, given that the language already has selective
  30. export declarations (a class may restrict the allowed client classes
  31. for each feature separately).  It should be declared in the feature
  32. declaration, and the routine would then have available an identifier
  33. 'Client', similarly to 'Current'.
  34.  
  35. If the client's identity were automatically available to all features,
  36. it might make sense to have also another identifier, 'External_client',
  37. for the uppermost feature call on the call stack that was made through
  38. a variable, not simply to Current.
  39.  
  40. Well, a rather loose idea.  Please develop further or shoot it down
  41. (the latter being my own favourite hobby, of course).
  42.  
  43. ----------------------------------------------------------------------
  44. Markku Sakkinen (sakkinen@jytko.jyu.fi)
  45.        SAKKINEN@FINJYU.bitnet (alternative network address)
  46. Department of Computer Science and Information Systems
  47. University of Jyvaskyla (a's with umlauts)
  48. PL 35
  49. SF-40351 Jyvaskyla (umlauts again)
  50. Finland
  51. ----------------------------------------------------------------------
  52.