structure [animal] :: looks hat
value [name] :: looks
value [location] :: looks

create instance of  [animal v] with values [Rabbit] [grasslands] named [rabbit] :: looks

< value [name v] of [rabbit v] :: looks >

structure [enemy] :: looks hat
value [id] :: looks
value [health] :: looks

Crispydogs101 wrote:

How does the value term work in python?

>>> class Animal:
...    def __init__(self, name, location):
...        self.name = name
...        self.location = location
... 
>>> rabbit = Animal("Rabbit", "Grasslands")
>>> rabbit.name
'Rabbit'
>>> rabbit.location
'Grasslands'
>>>

__Falcon-Games__ wrote:

Crispydogs101 wrote:

How does the value term work in python?

This is for kids so of course it's drastically simplified but in Python to have “values”, you use self.valuename like this.

>>> class Animal:
...    def __init__(self, name, location):
...        self.name = name
...        self.location = location
... 
>>> rabbit = Animal("Rabbit", "Grasslands")
>>> rabbit.name
'Rabbit'
>>> rabbit.location
'Grasslands'
>>>

__Falcon-Games__ wrote:

Scratch is a good language for absolute beginner kid programmers but I think that this suggestion could be implemented to make it easier for those kids when they transition from Scratch to a text-based programming language like Python or Javascript.

It is adding structures to Scratch, let me explain. There will be a new section, Structures, here you'll be able to add structures. There will be an Add Structure button to add one. A structure will be able to contain named attributes, for example an animal structure could contain the name of the animal and where the animal lives.

structure [animal] :: looks hat
value [name] :: looks
value [location] :: looks

You will now be able to create instances of structures via dragging the block for the structure from the Structures section.

create instance of  [animal v] with values [Rabbit] [grasslands] named [rabbit] :: looks

This will have a new type of a variable, instances, these variables will have nested values which you will be able to access.

< value [name v] of [rabbit v] :: looks >

Basically these are simpler to understand for kids version of classes, they will be a big help in making complex projects with complex objects that could now be represented with structures, for example you could represent enemy data with structures.

structure [enemy] :: looks hat
value [id] :: looks
value [health] :: looks

For projects that have a lot of different type of data and a lot of objects like big games for example with tons of enemies, it would make their code way more cleaner. This would also help kids transition from block-based programming to text-based programming. You might be asking though, will a eight year old understand this?. It is a more complex concept so it might take them a while for them to get to the stage of understanding it but it can be summed up simply through “you have these variables, now you can create containers that can have multiple variables”, It's usefulness in creating big projects outweighs it's challenges to learn for eight year olds and it's difficulty to implement. It might be a bit difficult but it's similar to lists but with named values, so some code from lists could be copied. At the end of the day I truly think that this feature will be very useful for the Scratch community to a point that exceeds it's difficulty to learn and implement. What I have put in this post is just an example of how it could be implemented, it could be made more simpler or could be made to use less sections, basically it could be adapted to how the ST will think it will be understandable for kids and will be useful for the Scratch community but the basic idea is that structures will be easier to understand and overall simpler versions of classes that could hold multiple named variables and could have instances of them made.

WindowsMeRules2000 wrote:

(#6)
This is literally just lists, no support

CST1229 wrote:

WindowsMeRules2000 wrote:

(#6)
This is literally just lists, no support

Lists are inconvienient for working with anything that has multiple instances of it or has named indexes (especially since Scratch also doesn't have custom reporters or temporary variables).

WindowsMeRules2000 wrote:

CST1229 wrote:

WindowsMeRules2000 wrote:

(#6)
This is literally just lists, no support

Lists are inconvienient for working with anything that has multiple instances of it or has named indexes (especially since Scratch also doesn't have custom reporters or temporary variables).

Then just make another list with indexes

blablablahello wrote:

(#11)
Isn't this basically object oriented programming? Pretty sure scratch is already object oriented due to the existance of sprites, clones, and local variables? I dont see how this would add anything to scratch except maybe a different way of understanding class, as they dont provide any new functionality (I guess you could use these to make easier stamp clones, but when you're using stamps as clones, you should be advanced enough to make systems like this without a specific inbuilt one)

< [habitat v] of < [animal v] of [myrabbit v] :: looks > :: looks >

blablablahello wrote:

Isn't this basically object oriented programming? Pretty sure scratch is already object oriented due to the existance of sprites, clones, and local variables? I dont see how this would add anything to scratch except maybe a different way of understanding class, as they dont provide any new functionality (I guess you could use these to make easier stamp clones, but when you're using stamps as clones, you should be advanced enough to make systems like this without a specific inbuilt one)

cookieclickerer33 wrote:

snip-
Not really

Object oriented programming from what I know is having multiple sprites and one main script that controls those sprites

In scratch each sprite has its own script and the 2 cannot command eachother programatically apart from broadcasts, but those are just entirely Un ideal

CST1229 wrote:

snip-
The thing with clones is that it's hard to access variables from other clones (you could use a list that clones put their variables into, but you could just not use clones altogether at that point), as the `of` block only accesses the original sprite.

blablablahello wrote:

cookieclickerer33 wrote:

snip-
Not really

Object oriented programming from what I know is having multiple sprites and one main script that controls those sprites

In scratch each sprite has its own script and the 2 cannot command eachother programatically apart from broadcasts, but those are just entirely Un ideal

True, but they're similar enough due to the “when I start as a clone” header.

CST1229 wrote:

snip-
The thing with clones is that it's hard to access variables from other clones (you could use a list that clones put their variables into, but you could just not use clones altogether at that point), as the `of` block only accesses the original sprite.

Indeed that is an issue, however, it would be more easily solved via the other suggestion about allowing accessing variables of clones and stuff (which also comes with naming clones)

cookieclickerer33 wrote:

snip-
I think at this point it would be easier to switch over to an entirely different language then have st add this and need to learn it

blablablahello wrote:

cookieclickerer33 wrote:

snip-
I think at this point it would be easier to switch over to an entirely different language then have st add this and need to learn it

Agreed. My main point is that although this suggestion might be slightly helpful, it overlaps with too much of clones and local variables to be worth it to add. If people really wanted/needed this, editing clones would be a better choice

__Falcon-Games__ wrote:

Surprisingly, this is getting support. One thing I will add to this is that there should probably be a way to nest structures because it makes sense that containers can have containers that have containers and so on because the kids probably know from the physical world that things can nest and that would actually help a thousand times more with complex projects. Like if you could do this:

< [habitat v] of < [animal v] of [myrabbit v] :: looks > :: looks >

Maybe this is too complex though, I am not really sure.