Re: reusing "code entities" without oop

Stephen M. Gava wrote:
Since we've been evaluating tcl/tk for a project I've found it asserted in several places in documentation that most things that you might use oop for in other languages are achievable in a non oop way in tcl.

In python for instance (using tkinter) you might make a tailored tk control, or even a whole toplevel with all its functionality, an object. You can then instantiate this object any number of times as a way of reusing this packaged functionality.

What would be the "standard" (non oop) tcl way of acheiving this outcome, or would the best answer be to use one of the oop "addons" for this purpose?

The reason I ask is that the simplicity of pure tcl/tk is compelling for deployment reasons, but if things like the "instantiation effect" need non core addons then it probably makes more sense for us to go with a combination of python (which we are more familliar with) and tk (via tkinter).

There are ways to do this in pure Tcl. However, if your primary purpose is to create re-useable Tk components, then I'd recommend using Snit (http://wiki.tcl.tk/snit). It is itself pure Tcl code, and is very well polished for this kind of work.

-- Neil
.

Relevant Pages

  • Re: reusing "code entities" without oop
    ... in several places in documentation that most things that you might use oop for in other languages are achievable in a non oop way in tcl. ... The reason I ask is that the simplicity of pure tcl/tk is compelling for deployment reasons, but if things like the "instantiation effect" need non core addons then it probably makes more sense for us to go with a combination of python and tk. ... You will find examples of snit widgets in the tklib 'widget' package (also in ActiveTcl). ...
    (comp.lang.tcl)
  • reusing "code entities" without oop
    ... Since we've been evaluating tcl/tk for a project I've found it asserted ... oop for in other languages are achievable in a non oop way in tcl. ... deployment reasons, but if things like the "instantiation effect" need ... non core addons then it probably makes more sense for us to go with a ...
    (comp.lang.tcl)