Re: My hang-up about OOP (snit)

Luc <luc@sep.invalid> wrote:

On Wed, 26 Jun 2024 22:32:17 -0000 (UTC), Rich wrote:
 

As a thought experiment, consider how you'd make your 'dog' proc
'count' (say you have circus dogs that can 'count' ...) and imagine
how to give each of four different dogs their own, independent,
counter to store their current value into.
>
Then, compare the code you'd need to add to the dog proc to make a
'counting dog' proc with separate counter variables for each dog to
the code necessary to achieve the same result from the counting class
above.

 
lassign "1 1" c_01 c_02
 
proc countcees {cee}    {
        upvar \#0 $cee _cee
        incr _cee
        puts $_cee
}
 
countcees c_01
2
countcees c_01
3
countcees c_02
2
countcees c_02
3
countcees c_01
4
 
 
In reality though, nobody needs a proc for that.

True, but you are missing the forest for the trees.

Imagine extending your example above to 273 different "counters" (or
managing 273 different sets of complicated [more than just a single
counter] pieces of independent data) or imagine managing 15 different
windows with differing (not shared) data, in the same app.

That's the point, the "do it with a proc and a bunch of globals"
method, where you have to modify the code to extend from 14 to 15 windows
(and likely have to add a 15'th 'then' clause to 95 different 'if'
statements) vs.  having the system handle the "separation" details and your code
change to go from 14 to 15 is to to just create 15 objects instead of 14.