Hey,
I was just wondering if there are any plans to enable the user to assign code to the stage of a project (as is possible in Snap)?
This way, the stage could act as a "main"-class. From the example projects, I've noticed that a number of them use some sort of class that controls or manages the rest of the program (see "Dots", or "ElectricField"). Maybe the stage could act as a central managing "main" class?
Assigning code to the stage?
Moderator: MSandro
Re: Assigning code to the stage?
I think the class/instances approach lends itself to having a "stage" as the equivalent of a main program method that invokes instances of other classes
Or as Sven says - it could just be a default class there on new project (as/instead of MyClass is at present)
It would certainly make things more familiar to users coming from Scratch.
But I can see this request as being part of the whole bigger issue of what should GP default to on startup/new class creation
Or as Sven says - it could just be a default class there on new project (as/instead of MyClass is at present)
It would certainly make things more familiar to users coming from Scratch.
But I can see this request as being part of the whole bigger issue of what should GP default to on startup/new class creation
Re: Assigning code to the stage?
This idea has been discussed amongst the GP team.
It has the advantages you both mention, but it also adds complexity. The Stage needs a different palette than other objects (e.g. no motion blocks), and it always has exactly one instance.
I'd like to stick with the current design for now but maybe revisit this question in 8-12 months.
It has the advantages you both mention, but it also adds complexity. The Stage needs a different palette than other objects (e.g. no motion blocks), and it always has exactly one instance.
I'd like to stick with the current design for now but maybe revisit this question in 8-12 months.
Re: Assigning code to the stage?
That's a good point. I can see how the added complexity with having a class that's the "main" class could be confusing for newcomers and novices. Similar to the subject of main methods such as those in Java or C: they are methods, but with slight differences, and so on...JohnM wrote: ↑Jul 14th, '17, 12:28This idea has been discussed amongst the GP team.
It has the advantages you both mention, but it also adds complexity. The Stage needs a different palette than other objects (e.g. no motion blocks), and it always has exactly one instance.
I'd like to stick with the current design for now but maybe revisit this question in 8-12 months.
Seems like a complicated issue.
Maybe another approach could be to automatically create an additional, invisible "main" class (one that has no morph associated with it, like helper-classes) on project creation. Then the concept could be merged with that of helper-classes: they could be limited to one instance, and not have access to "Looks"-blocks (which currently trigger the debugger) and any other blocks that are unsuitable for them?