So normally how people do OOP in Snap! is by either using lists or a sprite. One problem of this that it cannot have a custom look (for when it pops up in a bubble. you can have a costume as the start of the sprite, but you cant change that really after the fact). However, after digging in Snap! source code, I found a way. Its better to just put it here:
It starts by using JS to create a new sprite. Then we create a function - which will return the costume with the object graphics! Then we go BACK into JS, to override the default getImage of SpriteMorph to instead get the costume of the render function, and get the ".contents" (a canvas with the costume, which is what getImage returns).
Then we finally do a test using forever (every loop will show another letter).
And that's how I did it! I might make a actual library for this soon.
Update: I did!
Simply go to this project and see inside:
Now that we have yet another kind of OOP, using dictionaries and including inheritance, on Jens's short list (which means, it's gonna happen, although no promises about when) is the ability to specify a "display form" attribute of an object, which will be a Snap! function that reports what the object should look like in SAY, watchers, etc. My favorite example is the one for exact rational numbers:
but of course the function will also be able to report a costume.
My favorite example is the one for exact rational numbers:
When I was (trying) to make this into a library (I gave up because Snap! froze on errors 2 times) I did (try) to create a fraction class I used excatly that in the render function (of course with text costumes though).
Sorry, my grammar was ambiguous, I guess. What's on Jens's short list is the part about programmable display format.
Why of course? Some kinds of objects need graphics for their representation, but exact rationals work fine as text.
Lists as dictionaries have been around for quite a while (i.e., ITEM taking a non-numeric text as the first input). What's new in 10.1 is that if a dictionary/object has a field named "..." (chosen to avoid the need for translation) whose value is another object, then requests for fields not found in this object will be forwarded to the parent (the "..." object).
I already have the up in orginal post that I am working on the library. And you just try to use it?
why use javascript?
Because, ITS REQUIRED FOR THIS. Without Javascript, I could not create a blank sprite nor could I modify the getImage.
also, what does the "this" input in the function block do?
You're probably talking about this:
The whole POINT of functions on classes is to modify the class. The "this" input is just the object the function was called in - so you can modify it.
You can use the library again. I added a couple comfort features (casts to and from snap! types, allow getting the type of a object, and finally a function block without arguments).
First of all - the code where I need JS is already put in the first post:
But also, if you REALLY want, heres the part in the library at the moment thats the main reason I need JS (note, I also use JS for the internals for the object thing; but why not? I already use JS here):
It's better to only use js when you need it, rather than use it for everything since you need it for one thing. Basically the best way to put it is, it's better to write scripts in snap when and if you can, and only use js when you can't. At least that's my philosophy (and I feel like tge snap devs will agree with me on this).
It is possible to create a blank sprite in snap, just use (a new clone of [[Turtle sprite] V]) and if you need it in the sprite pane, just tell it to set [my temporary? V] to <<false>>
