As you know I'm a long term Scratcher and some recent Python experience (did C++/VB a long long time ago)
So Scratch disguises some high CS stuff by the sprite paradigm.
Now I'd term sprites as basically objects but missing some ways of interacting with them
BYOB/Scratch2 came along with clone concept and now we sort of have classes (orig sprite) and instances of the class (clones)
Please correct me if wrong so far :)
Now in GP - its grown up time and we have naked classes and instances.
Now for all simple stuff, I'm going to be working with just the one class.
But, it seems to me, that I'm actually working with a default instance of the class
or Am I working with a static instance of a class or .........
So question is - do I talk about the something in my instance or should I talk about my class or can i use "working with my object/object scripts etc" - which is right - or the least wrong :)
Obviously once we get into multiple instances of a class then life actually becomes clearer but I'm having trouble with the actually simple stuff :)
I hope this makes sense
I just want to make sure I don't tell any 11 year olds the wrong thing as they move on from Scratch :)
So can we have the definitive answer please (but make sure I can understand it)
Simon
Correct terminology to use
Moderator: MSandro
Re: Correct terminology to use
Further thoughts
classes are definitions of objects - yes?
instances are the actual objects created from the class definition - yes?
Are we just saying that in GP - each class does/must have a least one instance that cannot be programmaticly removed but other copies can be programmaticly created? (apologisies for word mangling!)
Simon
classes are definitions of objects - yes?
instances are the actual objects created from the class definition - yes?
Are we just saying that in GP - each class does/must have a least one instance that cannot be programmaticly removed but other copies can be programmaticly created? (apologisies for word mangling!)
Simon
Re: Correct terminology to use
Hi Simon,
I think you've pretty much gotten it straight :-)
Yes: Classes are "blueprints" for objects. A class defines the structures of its instances, i.e. the "fields" or instance variables and the "methods" or custom blocks. When an object is "born" by instantiating a class it inherits the structure but the new instance must be initialized so the "fields" actually have individual values. That's the main difference to cloning a prototype in BYOB (and in the upcoming Snap release), where the clone not only shares the prototype's structure, but also its values.
Yes: In GP each class in the authoring system automatically has at least one instance. This instance is neither a prototype nor an "achetype", but merely an example (a regular instance) of the class, whose values you can change in the GUI or through blocks. The only thing that matters to the class is the structure, not the values.
It is a matter of debate whether that concept is "grown up" :-)
I think you've pretty much gotten it straight :-)
Yes: Classes are "blueprints" for objects. A class defines the structures of its instances, i.e. the "fields" or instance variables and the "methods" or custom blocks. When an object is "born" by instantiating a class it inherits the structure but the new instance must be initialized so the "fields" actually have individual values. That's the main difference to cloning a prototype in BYOB (and in the upcoming Snap release), where the clone not only shares the prototype's structure, but also its values.
Yes: In GP each class in the authoring system automatically has at least one instance. This instance is neither a prototype nor an "achetype", but merely an example (a regular instance) of the class, whose values you can change in the GUI or through blocks. The only thing that matters to the class is the structure, not the values.
It is a matter of debate whether that concept is "grown up" :-)
Re: Correct terminology to use
Following this discussion and the chat on twitter today I'm thinking that in the truest CS sense, there should be no default instances when we create a class and then any confusion goes away.
All instances would have to be created (either programmatically e.g like the SetUp class does in the RabbitGrass demo) or manually by having say a + button next to a class.
Downsides
Its more work to click on a + button but I think it is much more explicit (and I believe in the Python way that explicit is better than implicit - especially for beginners) and would separate classes and instances which are blurred on first coming to GP from Scratch
The stage would be also be empty on a new project and beginners would have to learn to hit the + instance button, so that does raise the barrier for entry as we say in Scratch :)
This is where I'm up to with my thinking :)
All instances would have to be created (either programmatically e.g like the SetUp class does in the RabbitGrass demo) or manually by having say a + button next to a class.
Downsides
Its more work to click on a + button but I think it is much more explicit (and I believe in the Python way that explicit is better than implicit - especially for beginners) and would separate classes and instances which are blurred on first coming to GP from Scratch
The stage would be also be empty on a new project and beginners would have to learn to hit the + instance button, so that does raise the barrier for entry as we say in Scratch :)
This is where I'm up to with my thinking :)