Re: My hang-up about OOP (snit)

At Wed, 26 Jun 2024 22:32:17 -0000 (UTC) Rich <rich@example.invalid> wrote:

 
Luc <luc@sep.invalid> wrote:

And how is that better than this:
 
proc dog {dogname args} {
        if {$args == "tail wag"}        {return "$dogname Wag, wag"}
        if {$args == "tail droop"}      {return "$dogname Droop, droop"}
        if {$args == "eats food"}       {return "$dogname Nom, nom"}
        if {$args == "goes to vet"}     {return "$dogname Tries to run"}
 
}
puts [dog fido tail wag]
puts [dog lucky tail droop] 
puts [dog charlie eats food]
puts [dog mitts goes to vet]
 
That will handle multiple dogs pretty well.
 
One "method," one "if." It's pretty much it, isn't it?

 
The Tcl 'my' manpage provides a very simple example that should help
illuminate why the 'object' method would be better than your 'dog'
example above.
 
The 'class' example it gives is (modified slightly below):
 
    % oo::class create c {
      variable counter
      method count {} {
        puts [incr counter]
      }
    }
    ::c
 
This creates a class command 'c' that will create objects.  So lets
create two objects, o1 and o2:
 
    % c create o1
    ::o1
    % c create o2
    ::o2
 
Now, what we have is two objects, that each have their own "counter"
variable.  The 'counter' variable is not shared between them.  Watch
this below:
 
Make o1 count a few times:
 
    % o1 count
    1
    % o1 count
    2
    % o1 count
    3
    % o1 count
    4
    % o1 count
    5
 
Now, make o2 count for the first time:
 
    % o2 count
    1
 
o2 returns 1, not 6, so its 'counter' variable is separate from the
'counter' variable in o1 (which is presently storing the value '5').
 
Now make them both count once each again:
 
    % o1 count
    6
    % o2 count
    2
 
o1 knows it was at 5, and so it returns 6, and o2 knows it was at 1, so
it returns 2.
 
And, note, this example got this "separation" of data automatically,
from just this little bit of 'code':
 
    % oo::class create c {
      variable counter
      method count {} {
        puts [incr counter]
      }
    }
 
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.

And to totally blow Luc's mind, consider this "class":

snit::widgetadaptor ROText {
    delegate method * to hull
    delegate option * to hull except {-background -borderwidth -font
        -foreground -highlightbackground -highlightcolor -highlightthickness
        -relief -insertbackground -selectbackground -insertborderwidth
        -selectborderwidth -selectforeground -padx -pady}
    typeconstructor {
        ttk::style configure ROText \
              -background ttk::theme::default::colors(-frame) \
              -borderwidth 1 \
              -font TkFixedFont \
              -foreground black \
              -relief sunken \
              -selectbackground ttk::theme::default::colors(-selectbg) \
              -selectborderwidth  1 \
              -selectforeground ttk::theme::default::colors(-selectfg) \
              -padx 0 -pady 0
    }
    option -style -default ROText
    method _themeUpdated {} {
        #puts stderr "*** $self _themeUpdated"
        foreach o {-background -borderwidth -font -foreground
            -highlightbackground -highlightcolor -highlightthickness -relief
            -insertbackground -selectbackground -insertborderwidth
            -selectborderwidth -selectforeground -padx -pady} {
            if {![catch {ttk::style lookup $options(-style) $o} ov]} {
                #if {"$ov" eq ""} {continue}
                #puts stderr "*** $self _themeUpdated: $o $ov"
                catch {$hull configure $o $ov}
            }
        }
    }
    constructor {args} {
        installhull using text
        $self configurelist $args
        set indx [lsearch [bindtags $win] Text]
        bindtags $win [lreplace [bindtags $win] $indx $indx ROText]
        bind $win <<ThemeChanged>> [mymethod _themeUpdated]
        $self _themeUpdated
    }
}

(A large chunk of the code is ommited -- the full file is here:
https://github.com/RobertPHeller/ModelRRSystem/blob/master/trunk/Scripts/Common/snitrotext.tcl
-- the whole laundry list of bindings are left out
)

What this deceptively simple "widgetadaptor" does is two things: It "wraps"
around the Tk "text" widget and makes it readonly (not user editable) -- great
for things like log output, etc. At the same time, it makes it themed, just
like the various ttk:: widgets. (A snit::widgetadaptor is a special case of a
snit::type intended to "wrap" around an arbitary widget.)

The only methods added are the theme related methods. It takes away the old
school styling options (-background -borderwidth -font -foreground, etc.) and
replaces them with a -style option. It also changes the bindtags to remove the
text insert key and mouse bindings (eg generic key press and paste bindings).
Otherwise it is otherwise just like a garden variety text widget. Note that
this in fact leverages the fact all of Tk's widgets are in fact functionally
OO, dispite being coded in plain C. Actually *lots* of Tcl is functionally OO,
dispite not technically being OO. SNIT can "inheirt" (delagate) to Tcl
"commands" that are not snit "types" -- all the commands have to have are a
functional structure like "<command> sub-command ..." and (optionally)
implement the configure and cget "methods" (sub-commands).

                                                       
 

--
Robert Heller             -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
heller@deepsoft.com       -- Webhosting Services