We have three entirely different ways to implement OOP.
The most natural way, in Snap!, is to use sprites as the objects. Sprites inherit attributes from their parent, and you can control exactly what is inherited. We use prototyping OOP, not class/instance, but if you HIDE a sprite then it serves precisely as a class for its clones. (You can hide the clones, too, if your application doesn’t need their graphics capabilities.)
You can use procedure closures to represent classes and instances, as in SICP chapter 3, or as in the Snap! Reference Manual, chapter VIII. If you do it that way, you can join the mysterious Knights of the Lambda Calculus and practice waving your arm in the air while saying “Objects are just closures.”
The newest way is to use dictionaries: lists of two-item lists, in which the first item of each sublist is a field name and the second item is its value. If the value is a procedure, it is taken as a method that the object calls to handle messages. If a field name is “…” (three dots, not a Unicode ellipsis) then the value should be another object, which is used as the parent of the current object.
I’m not sure what to say about THIS SCRIPT because it’s only in the second technique that objects are represented as procedures. But in technique 3, THIS OBJECT can be used inside a method to refer to the current object (even if the method was found in its parent). And of course in the first method, THIS OBJECT or MY SELF (both in Sensing) report the current sprite.
Methods 2 and 3 are class/instance, and, as I said, prototyping OOP can trivially simulate class/instance if you just refrain from actually having the parent do anything!
