You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So taking the neopixels as an example.
We currently have blocks, like the "clear", that are meant to only take "neopixel_object" type blocks as an input, to be used as an instance of the NeoPixel class, but due to the nature of the variable block you could attach any type of variable to this.
So you could set variable foo to 0 and then attach foo to the clear block to generate the equivalent of 0.clear().
Apart from that, even things like figuring out where the constructor block is meant to go is not very straightforward.
I was thinking if following the variables approach would be a better model for class instances? With or without the "create variable" button on the toolbox, but at least to have a way of creating instances (the previously mention button, or a block) and then blocks with a special dropdown that contains only the relevant instances.
The text was updated successfully, but these errors were encountered:
All good points. I spent quite a bit of time thinking about this when creating the NeoPixel related blocks and ended up coming to the conclusion that the best way forward was to "just do something" and revise thereafter. Ergo, this feedback is great.
To open things up more, here's my movement of thought that got me to where we're at right now.
When instantiating an object you (usually) assign it to something. Hence the "initialise pin X with Y neopixels" block returns something (the new object) you can assign to a name.
Blocks are a stepping stone to Python. How much blocks are for abstracting away Python or moving towards Python is moot. When I created the blocks, I was thinking about how to use the blocks to gently hint at thinking about how the Python code works (instantiate something to describe the neopixel setup, use the thing to act with NeoPixel related blocks to make stuff work). I'm not sure this works.
The indexing related block (the monster block) is horrendous.
Completely note that it's possible to attach objects of arbitrary types to the NeoPixel blocks.
I'm not sure I agree with you about following the variables approach. This has more to do with creating and assigning names than it does instantiating classes (from my point of view). They're two different things. Does this make sense..?
So taking the neopixels as an example.
We currently have blocks, like the "clear", that are meant to only take "neopixel_object" type blocks as an input, to be used as an instance of the
NeoPixel
class, but due to the nature of the variable block you could attach any type of variable to this.So you could set variable
foo
to0
and then attachfoo
to the clear block to generate the equivalent of0.clear()
.Apart from that, even things like figuring out where the constructor block is meant to go is not very straightforward.
I was thinking if following the variables approach would be a better model for class instances? With or without the "create variable" button on the toolbox, but at least to have a way of creating instances (the previously mention button, or a block) and then blocks with a special dropdown that contains only the relevant instances.
The text was updated successfully, but these errors were encountered: