Re: My hang-up about OOP (snit)

On Thu, 27 Jun 2024 02:33:58 -0000 (UTC), Rich wrote:

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.

The non OOP code used in this discussion could be better.  Here's an
alternative to the OOP code, which uses a dictionary although an array
could also be used.  This could easily be extended to more internal
variables and more methods on those variables.  It could even be argued
that this is OOP code in some respects.  The advantage this has over
normal OOP code is that you know what functions are actually being called
with the object.  That is my main gripe with most OOP, at times you have
no idea what functions are actually being called on an object and you have
to dig through the code until you work out what instantiated an object and
what the methods do on that particular object.


namespace eval counter {
  namespace export {[a-z]*}
  namespace ensemble create
}

proc counter::new {} {
  dict create count 0
}

proc counter::count {counterName} {
  upvar counterName counter
  dict incr counter count
  puts [dict get $counter count]
}

set counter [counter new]
counter count counter
counter count counter
counter count counter
counter count counter


Best wishes


Lorry

---
Modula-2 Compilers on CP/M
https://techtinkering.com/articles/modula-2-compilers-on-cpm/