Are both ok. First is more intuitive cause everything else is of shape sprite.doThing
In Scratch the IDE does the creation/association. So the design choice here is - should a Sprite be “magically” added to Stage upon construction. I chose not to because removing a Sprite is also a thing and symmetry is important.
But those are semantics - the whole thing is indeed OOP because... Scratch is OOP.
Sprites on a stage interact.
BlockLike didn’t invent any of it, it just attempts to creat a syntax that is as similar as possible to Scratch, thus allowing kids to use the same concepts and patterns they already know as a basis upon which to acquire new ones.
So while passing sprites around is valid javascript and valid in BlockLike (your example doesn’t work only because to expect your function do do something javascript can’t do out of the box - you expect it to wait) this is not really the way to go here. The way to go is simple, the sprite that invokes is “this” and if you want a click on one sprite to have an effect on another sprite, let another sprite invoke. (For playful fun the example has been updated: https://codepen.io/BlockLike/pen/JpjVOp?editors=1010)
But, here’s the interesting thing that “emerged out of the design” and that I really like - one learns that one can pass around functions.
.say() gets a string, .wait() gets a number. whenClicked() gets a function (so does invoke()). Those are methods of the Sprite. What else is a method that gets a function? How about forEach()? and from there it’s off to the races... ;)
> the whole thing is indeed OOP because... Scratch is OOP.
Right. I guess that's the core of my problem. I don't think you should be teaching beginning programmers OOP. It pollutes their minds too early and they don't appreciate the separation of data and code. And yes, I am biased because I dislike OOP.
In Scratch the IDE does the creation/association. So the design choice here is - should a Sprite be “magically” added to Stage upon construction. I chose not to because removing a Sprite is also a thing and symmetry is important.
But those are semantics - the whole thing is indeed OOP because... Scratch is OOP.
Sprites on a stage interact.
BlockLike didn’t invent any of it, it just attempts to creat a syntax that is as similar as possible to Scratch, thus allowing kids to use the same concepts and patterns they already know as a basis upon which to acquire new ones.
So while passing sprites around is valid javascript and valid in BlockLike (your example doesn’t work only because to expect your function do do something javascript can’t do out of the box - you expect it to wait) this is not really the way to go here. The way to go is simple, the sprite that invokes is “this” and if you want a click on one sprite to have an effect on another sprite, let another sprite invoke. (For playful fun the example has been updated: https://codepen.io/BlockLike/pen/JpjVOp?editors=1010)
But, here’s the interesting thing that “emerged out of the design” and that I really like - one learns that one can pass around functions.
.say() gets a string, .wait() gets a number. whenClicked() gets a function (so does invoke()). Those are methods of the Sprite. What else is a method that gets a function? How about forEach()? and from there it’s off to the races... ;)