[George Peter Staplin]: It has occured to me that much of Tk is about hiding the structure of a widget or gadget.  This greatly reduces the stress of using the toolkit, but it can become limiting.

The [canvas] is a great example of hiding structure.  If say you want to create a polygon with a red color it's as simple as:

 pack [canvas .c] -fill both -expand 1
 .c create polygon 10 10 150 150 200 200 130 100 -fill red

Tk is hiding many aspects of the structure of that object you just created.  For instance there is a '''graphics context/GC''', an '''XColor''' allocated, information about how to redraw it, etc.  The canvas takes care of redrawing it when an Expose or Configure event occurs without us telling it to.

Now obviously if we just created objects this way it would be limiting and we would run out of memory.  So, the canvas returns a unique id for each object and that can be considered a name for our structure.   We can delete the object and the hidden structure behind it.

The concept of a tag (which may have originated in Ezd) was introduce to allow having an easier method of referring to an object than the tag returned by the creation.  The tag also allows classifying objects.

This all sounds great, but then you decide "I want to manipulate Object to do X."  Usually this means writing a procedure that manipulates the object via the '''coords''' or '''scale''' subcommands.   As the amount of changes you want to make to the object increases your number of global or namespace procedures grows.  Then you may decide in the future "I want to create another instance of this."  So, then you create two or more widgets and probably redesign some of your work to '''restructure''' the code to work in this manner.  The canvas and your procedures are not a unit.  Changes made in one part may adversely affect another.

[global procedures]
[then you want to use two instances]