Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Luc <luc@sep.invalid>
Newsgroups: comp.lang.tcl
Subject: Re: My hang-up about OOP (snit)
Date: Wed, 26 Jun 2024 22:09:32 -0300
Organization: A noiseless patient Spider
Lines: 124
Message-ID: <20240626220932.62b9e27e@lud1.home>
References: <20240625180928.43fcc5c1@lud1.home>
	<ILKcnRhLs7Cl9eb7nZ2dnZfqnPqdnZ2d@giganews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 27 Jun 2024 03:09:33 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="45a762fadea9095f510d51d9df4273ce";
	logging-data="2529711"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/fP8h3d+xm+sYvELc1jbXD4Z5K/2VPStU="
Cancel-Lock: sha1:v73rfRPE9NXNPyDFe5SXgVksXsM=
Bytes: 4630

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