home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / tcl / 2488 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  1.3 KB
  1. Path: sparky!uunet!ukma!bogus.sura.net!darwin.sura.net!haven.umd.edu!ni.umd.edu!sayshell.umd.edu!louie
  2. From: louie@sayshell.umd.edu (Louis A. Mamakos)
  3. Newsgroups: comp.lang.tcl
  4. Subject: Re: Multiple Interpreters
  5. Date: 28 Jan 1993 14:45:45 GMT
  6. Organization: The University of Maryland, College Park
  7. Lines: 22
  8. Message-ID: <1k8ripINNqcu@ni.umd.edu>
  9. References: <1993Jan28.033005.23086@wuecl.wustl.edu>
  10. NNTP-Posting-Host: sayshell.umd.edu
  11.  
  12. In article <1993Jan28.033005.23086@wuecl.wustl.edu> omar@wucs1.wustl.edu (Omar El-Ghazzawy) writes:
  13. >
  14. >I know there must be many good uses for having multiple interpreters, but
  15. >I can't seem to think of any.
  16.  
  17. I have an application that I'm developing which associates some TCL
  18. "state" with Objective-C objects.  The Object has methods which are
  19. invoked by TCL commands, etc.  The great thing about having multiple
  20. interpreters available is that you have a seperate name space (both
  21. for commands and variables) which reflect the existing objects and
  22. classes in the program.
  23.  
  24. I haven't hacked his stuff into my code yet, as I'm "faking" much of
  25. it now, but I look forward to giving it a try.  It seems just perfect
  26. for my application.
  27.  
  28. Actually, it would be great if a new interpreter could inherit
  29. methods/commands from the "super class" or the interpreter that
  30. created it, but I can see how that might be difficult to implement.
  31.  
  32. Louis Mamakos
  33.  
  34.