Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should class instances follow the same block model as variables? #7

Open
carlosperate opened this issue Dec 10, 2016 · 1 comment
Open

Comments

@carlosperate
Copy link
Member

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.

@ntoll
Copy link
Contributor

ntoll commented Dec 14, 2016

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..?

Thoughts? I'm all ears for suggestions!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants