Assigning code to the stage?

Questions about GP commands and how to do things

Moderator: MSandro

Post Reply
SvenJ
Posts: 25
Joined: Jul 6th, '17, 08:03

Assigning code to the stage?

Post by SvenJ » Jul 13th, '17, 12:18

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?

SimpleSi
Posts: 330
Joined: Jul 2nd, '17, 13:47

Re: Assigning code to the stage?

Post by SimpleSi » Jul 13th, '17, 15:22

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

JohnM
Posts: 379
Joined: Sep 11th, '15, 14:42

Re: Assigning code to the stage?

Post by JohnM » Jul 14th, '17, 12:28

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.

SvenJ
Posts: 25
Joined: Jul 6th, '17, 08:03

Re: Assigning code to the stage?

Post by SvenJ » Jul 14th, '17, 12:39

JohnM wrote:
Jul 14th, '17, 12:28
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.
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...

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?

Post Reply