Re: reusing "code entities" without oop

In article <460C0B0A.4060508@xxxxxxxxxxxxxxx>,
Jeff Hobbs <jeffh@xxxxxxxxxxxxxxx> wrote:
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).

While OO is often overused, it is actually useful in UI programming and
for the building of megawidgets in particular. I would recommend using
the 'snit' module in tcllib (part of ActiveTcl). It is conceptually
clean and easier to use. You will find examples of snit widgets in the
tklib 'widget' package (also in ActiveTcl).

Jeff

All true, along with the remarks of Bryan, Aric, Gerald, and the others.

I remain suspicious that there's an even more elementary answer. While
I don't have time before next week to engage in much of a conversation,
I suspect this thread as it stands underestimates the extent to which
simple procedural "factory functions" are the aptest idiom for many GUI
programming chores. In the sentence, "You can then instantiate this
object any number of times as a way of reusing this packaged
functionality", is "reuse" something that's taking place across or
within applications? Is the point to manage several instances within
what the end-user sees as a single program, or to stockpile useful parts
for a team of developers working on many programs?

.

Quantcast