Is there oop in snap?
This question has been already asked by me.
1 Like
No, no, no. Wrong answer. (We built the ability to interface with JavaScript into Snap!, but @18001767679 is one of the people who use it as their first resort, rather than the last resort as we intended.)
Snap! has very good support for object-oriented programming, in two different ways, each of which has a chapter in the Reference Manual.
One way uses Snap!'s natural objects: sprites. Even before we set out to make them full objects, they already had the ability to have sprite-local variables and sprite-local procedures (methods). The main thing that we had to add was inheritance. When you make a clone of a sprite, it isn't just a copy; it shares many characteristics with its parent by default, and can be told to share other things too. (For example, methods are shared by default, but sprite-local variables aren't, because too many projects use the idiom
so that each clone has its own ID.) There's message-passing with the TELL and ASK blocks. (TELL is a command; ASK is a reporter.) This is a prototyping OOP system, because kids making projects aren't like teams of adult programmers; the kid typically creates a sprite and experiments with its methods and general behavior before deciding to make more sprites like this one. So the first one is the prototype for all its clones.
The second way to do OOP is with closures as the objects. The local variables in a procedure call persist forever, instead of disappearing when the procedure finishes, if what the procedure returns is another procedure made by a lambda expression (a gray ring) in the body of the original procedure. It turns out to be very natural and easy to build a class/instance system based on closures.
its just what we do when we use clones in scratch but its not needed as we have fc sprites
I get it. (besides the noise of js)
You're welcome!
I'm not sure I understand this. Do you mean this:
It's true that that's a more understandable idiom, not dependent on timing. But alas, there are plenty of Snap! projects out there that do it the other way, so if we ever decided to go all the way with a new clone inheriting everything, we'd have to recognize old projects and treat them differently. I have this daydream about a Flag Day on which we implement all the changes we'd love to make but can't because of old projects, and then we have one change to the version number in the project and maintain the old behavior for old projects. But that would mean a lot of tests like
if (version < 3) ... and Jens hates putting tests in the Snap! code, which is why some of our error messages aren't very user-friendly.
no i dont mean that.
i mean a lot of local vars and use the [scratchblocks] ([local var v]of(item(i)of (my [clones v]::sensing))) [/scratchblocks]to parse the clones.
i recommend
or no clones just pen.