Re: My hang-up about OOP (snit)

On Wed, 26 Jun 2024 01:00:40 +0000, Robert Heller wrote:

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.

This is a really good explanation that got me interested. I've been
reading up on snit and I like what I see.

But I am stuck in this:

snit::widget TopWindow {
    hulltype toplevel
    delegate option * to hull
    component of

    constructor {args} {
wm withdraw $win
wm resizable $win 1 1
wm attributes $win -zoomed 1
wm geometry $win 60x10+0+0
wm title $win "test"
tk appname "test"
bind $win <Alt-q> {exit 0}
bind $win <Alt-Q> {exit 0}

set of [frame $self.of]
pack $of -fill both -expand 1

        $self configurelist $args
        puts "self is $self"
}
}

TopWindow .toplevel
puts [winfo children .]

output: .


The snit manual says:

"The body of a type constructor is executed once when the type is defined,
and never again."

So the part that defines frame $self.of should have been executed, right?
In which case, $self.of is a child of the toplevel widget, right?
Then how come puts [winfo children .] only outputs "." with no mention
of the frame?

Oh, the 'wm withdraw $win' line doesn't seem to be executed either. The
gray box still pops up.

--
Luc

>