I have a 'person' sprite with a sprite-only block called "spinLikeCrazy". From a script in another sprite, I want to tell person to "spinLikeCrazy". The Snap manual makes me think I can do this, but the only way I've been able to make it happen is by using the "of" function. As in "tell person to 'spinLikeCrazy of person'"
In "Sending Messages to Sprites", I read "Snap 4.1, following BYOB 3.1, used an extension of the of block to provide access to other sprites’ methods. That interface was designed back when we were trying hard to avoid adding new primitive blocks; it allowed us to write ask and tell as tool procedures in Snap iitself. That technique still works, but is deprecated, because nobody understood it, and now we have the more straightforward primitives."
I can't seem to find a non-hacky way to simply run person.spinLikeCrazy(). Ideas?? Thank you. (the other hacky ways I've made it work are via assigning the method to a global variable and by creating an empty script of the same name in my current sprite. ugh!) Any help much appreciated.
Open a Block Editor. (It doesn't matter what block you're editing; you can just fake one and delete it when done.)
With the block editor open, switch to the receiving sprite, and inside the block editor construct the instruction TELL [receiver] TO [spinLikeCrazy]. It can just be floating loose in the editor.
Then, in the sprite corral, click on the sending sprite.
And then drag the TELL block out of the block editor into the sprite's scripting area.
You should, imho, be able to just drag the spinLikeCrazy block directly from the receiver's palette onto the sender's icon in the sprite corral, but I just tried it, and you can't. I think that's a bug, but maybe it's a misfeature; we'll see what @jens says.
bh THANK YOU so much for the fast and helpful reply (and for the welcome). I am a Snap noob, so I'm sure I'll be banging my head a bit. But this trick to get a sprite's method available inside another sprite's scripts is gold. I am unblocked and plowing ahead. : ) Thank you again.
Please do not ever leave a Block Editor open while switching to another sprite in order to transport another sprite's private block in it. That's a sure way to corrupt your project. The misfeature is switching to another sprite should not even be possible while a Block Editor instance is open. I'm reluctant to enforce it, because I find it immensely useful to look up things in another sprite and to - for example - draw a costume in another sprite without having to close all block editors first. But, again, using the block editor to "hack" around Snap's object encapsulation WILL corrupt your project.
How do objects communicate? The overall idea is that a sprite can only ASK or TELL another sprite something it knows about itself. Since Snap! is blocks-based the ASKING sprite has to have a similar block in its own vocabulary that it's AKSING / TELLING the other sprite to perform. That block can have a different meaning / behavior for the TELLING sprite than for the TOLD one (polymorphism).
The only way for a sprite to request a private action from another sprite it does NOT have in its own vocabulary is to use the OF block. OF lets you "peek" into a subset of another sprite's private properties.
But NEVER use the block editor to "trick" Snap into giving you access to another sprite's internals.
OK, I shall not do any tricking and risk corrupting my project! (though it is a nice trick)
I will use the "OF" block method, and that will work fine.
However, the Snap manual could use some adjusting and augmenting in this area (I'd be happy to jump in and help, but I really don't know what I'm doing yet. : ) ) Especially the section "C. Sending Messages to Sprites" on pg. 56 of the 5.1 manual as well as "VII. Object Oriented Programming with Sprites" on pg. 55. Both these sections very much led me to believe I could create methods on a sprite and easily reference them elsewhere.
As for requiring phantom methods with the same signatures in the caller and calling it polymorphism, while maybe inside the lines of a formal definition, there is no way that that usage of polymorphism is not bending the brain of the new programmer, since those methods' only reason for being there is to hack around a lack of public methods. It would be great if sprite properties (variables and custom blocks) could be specified as either public or private... or if they were all simply public by default, since we already have access to them via the "OF" block.
Thanks for this project. I can see how powerful it is for new programmers. (I'm helping out one here, so I wanted to get up to speed myself.)
Any confusion in the manual comes from confusion on my part about how it works. But I figure that if I get confused, so will users, so Jens and I have to go back and forth for a while about a way to handle cross-sprite messages that makes sense for Jens (wrt implementability) and for me (wrt user comprehensibility). This happens sometimes, and we sometimes yell at each other for a while until we settle on something. :~)
The Snap! Reference Manual is very helpful. It answered the question, "What is this Snap! thing, and just what can I do with it?" My brain is still coming up to speed on the sweet spot of the language. And I hope to be helpful to my son as he's learning it. We both have prior Scratch experience, so the entry into Snap! did not feel too unfamiliar.
