Re: My hang-up about OOP (snit)

At Tue, 25 Jun 2024 18:09:28 -0300 Luc <luc@sep.invalid> wrote:

 
It's hard for me to accept OOP because as hard as I try I really can't
not think that OOP is the Emperor's new clothes.
 
Example from snit:
 
snit::type dog {
    method {tail wag}   {} {return "Wag, wag"}
    method {tail droop} {} {return "Droop, droop"}
}
dog spot
puts [spot tail wag]
puts [spot tail droop]
 
 
Why exactly is that any better than this:
 
proc dog {args} {
if {$args == "tail wag"}   {return "Wag, wag"}
if {$args == "tail droop"} {return "Droop, droop"}
}
puts [dog tail wag]
puts [dog tail droop]

snit::type greatdane {
    component common -inherit true
    constructor {args} {
        install common using dog %%AUTO%%
    }
    method bark {} {return "WOOF!"}
}

While the dog example is a bit silly and trivial, there are real world use
cases where this inheritence (delegation) game pays off handsomly.

It is partitularly usefull for megawidgets. Tk's base widgets are already
written in an OO style. Also snit "compiles" the code to be far more efficient
than either a stack of if's (or a cascade of if ... elseif ... else ...).  In
any case, something like:

snit::type foo {
    method a {} {...}
    method b {} {...}
    method c {} {...}
    method d {} {...}
    method e {} {...}
    method f {} {...}
    method g {} {...}
    method h {} {...}
    method i {} {...}
    method j {} {...}
}

is probably easier to read and debug than

proc foo {fun args} {
   if {$fun eq "a"} {
      ...
   } elseif {$fun eq "b"} {
      ...
   } elseif {$fun eq "c"} {
      ...
   } elseif {$fun eq "d"} {
      ...
   } elseif {$fun eq "e"} {
      ...
   } elseif {$fun eq "f"} {
      ...
   } elseif {$fun eq "g"} {
      ...
   } elseif {$fun eq "h"} {
      ...
   } elseif {$fun eq "i"} {
      ...
   } elseif {$fun eq "j"} {
      ...
   } else {
      error ...
   }
}

The other thing is that the dog example has no instance variables (or options)
-- this seems to make the use of OO pointless. Once you add in instance
variables and options, and start having multiple instances of the "type" (or
more significantly, widgets), you will want to have the common "code" in one
shared place and you will want to have some way of keeping track of instance
variables / instance options and that is of course the whole point of having
reusable widgets in the first place...

Single instance classes are pretty pointless -- so are classes where all
instances are totally identical (where all of the class instances are 100%
interchangable and carry no instance specific state).  That would like having
a "type" 42 (the specific integer with the specific value of 42).

There are sometimes "classes" like that: there are some specific use cases --
see "ENSEMBLE COMMANDS" in man snitfaq. I also use this to create "main"
programs where I can encapsulate "global" program data / constants /
parameters (as type variables). I don't really *need* to do this, but it keeps
things tidy and I don't need to use either '::' (global decls) all over the
place and don't have to worry about stepping on some other code's toes.


--
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