Re: My hang-up about OOP (snit)

At Tue, 25 Jun 2024 19:57:30 -0300 Luc <luc@sep.invalid> wrote:

 
On Tue, 25 Jun 2024 22:29:46 -0000 (UTC), Rich wrote:
 

If you only *ever* have one dog, either are essentially the same.
>
But, if at some point you want to manage spot, frank, sam, donut, and
alexa, all of which are different dogs, then you can do:
>
   snit::type dog {
       method {tail wag}   {} {return "Wag, wag"}
       method {tail droop} {} {return "Droop, droop"}
   }
>
Once to create a generic "dog" framework.
>
And then later do, all in the same single program instance:
>
dog spot
dog frank
dog sam
dog donut
dog alexa
>
And have five, fully independent dogs (each with their own independent
"data") that you can manipulate, without having to do anything special
at the time you create them.
>
I.e., you can wag spot's tail, give food to sam, and label alexa with
"last vet visit was 2024-06-21" (assuming you had mentods for 'feed'
and for 'last-vet-visit' in the generic framework.

 
 
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?

Nope.  How would you handle instance variables?  Options?  Dog breeds (which
would be implemented with derived classes with specialized methods, instance
variables and options)?  And with a large number of methods, etc., that if
very quickly becomes unweildly.

The dog example is probably a bad example to base ALL of OO on.  It was only
meant as a starting point, like:

proc HelloWorld {} {
   puts "Hello World"
}
HelloWorld

can be trivially replaced with:

puts "Hello World"

and from that *ALONE* one could argue that "proc" is pointless, totally
ignoring all of the other reasons why one would use proc.

 

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