Parts of Scratch 3 work by in some cases storing a string or integer identifier for an object instead of the object itself. The object may be a block, variable, list, broadcast message, drawable, or sound. Usually the code asks for the object with a given ID before invoking one of its methods or manipulating it; in some cases it maintains the indirection by instead asking another object to do something regarding the object with the ID.

What does this indirection do other than make the code more complicated and difficult to work with and slower and make the representation of Scratch projects less compact?

Jonathan50 wrote:

Parts of Scratch 3 work by in some cases storing a string or integer identifier for an object instead of the object itself. The object may be a block, variable, list, broadcast message, drawable, or sound. Usually the code asks for the object with a given ID before invoking one of its methods or manipulating it; in some cases it maintains the indirection by instead asking another object to do something regarding the object with the ID.

What does this indirection do other than make the code more complicated and difficult to work with and slower and make the representation of Scratch projects less compact?

I believe this is because JSON doesn't support pointers to objects.

Maximouse wrote:

Jonathan50 wrote:

Parts of Scratch 3 work by in some cases storing a string or integer identifier for an object instead of the object itself. The object may be a block, variable, list, broadcast message, drawable, or sound. Usually the code asks for the object with a given ID before invoking one of its methods or manipulating it; in some cases it maintains the indirection by instead asking another object to do something regarding the object with the ID.

What does this indirection do other than make the code more complicated and difficult to work with and slower and make the representation of Scratch projects less compact?

I believe this is because JSON doesn't support pointers to objects.

Why would that be necessary if the blocks could just be stored in an array like in Scratch 2.0?

Sheep_maker wrote:

Maximouse wrote:

Jonathan50 wrote:

Parts of Scratch 3 work by in some cases storing a string or integer identifier for an object instead of the object itself. The object may be a block, variable, list, broadcast message, drawable, or sound. Usually the code asks for the object with a given ID before invoking one of its methods or manipulating it; in some cases it maintains the indirection by instead asking another object to do something regarding the object with the ID.

What does this indirection do other than make the code more complicated and difficult to work with and slower and make the representation of Scratch projects less compact?

I believe this is because JSON doesn't support pointers to objects.

Why would that be necessary if the blocks could just be stored in an array like in Scratch 2.0?

Yes exactly!

Sheep_maker wrote:

Maximouse wrote:

Jonathan50 wrote:

Parts of Scratch 3 work by in some cases storing a string or integer identifier for an object instead of the object itself. The object may be a block, variable, list, broadcast message, drawable, or sound. Usually the code asks for the object with a given ID before invoking one of its methods or manipulating it; in some cases it maintains the indirection by instead asking another object to do something regarding the object with the ID.

What does this indirection do other than make the code more complicated and difficult to work with and slower and make the representation of Scratch projects less compact?

I believe this is because JSON doesn't support pointers to objects.

Why would that be necessary if the blocks could just be stored in an array like in Scratch 2.0?

Probably because Blockly uses some kind of linked lists to represent blocks: every block has pointer to the next block.

Maximouse wrote:

Probably because Blockly uses some kind of linked lists to represent blocks: every block has pointer to the next block.

I wonder if they do this so that if a script is running and you pull a chunk of currently running blocks out, it'll still know which block to run next

With this script:

when [space v] key pressed
forever
turn cw (15) degrees
end

In Scratch 2.0, after pressing space, you can drag out the forever loop and it'll continue to rotate, but it'll only glow the when space key pressed block. Scratch 3.0 is similar except it correctly glows the forever script instead of when space key pressed.

Sheep_maker wrote:

Maximouse wrote:

Probably because Blockly uses some kind of linked lists to represent blocks: every block has pointer to the next block.

I wonder if they do this so that if a script is running and you pull a chunk of currently running blocks out, it'll still know which block to run next

With this script:

when [space v] key pressed
forever
turn cw (15) degrees
end

In Scratch 2.0, after pressing space, you can drag out the forever loop and it'll continue to rotate, but it'll only glow the when space key pressed block. Scratch 3.0 is similar except it correctly glows the forever script instead of when space key pressed.

But aren't Scratch-Blocks and Scratch-VM very separate? Storing block next-next data in JSON would seem silly, no?

Maximouse wrote:

I believe this is because JSON doesn't support pointers to objects.

Alright, the way Scratch 3 represents blocks involves cyclic structure (stacks are represented as blocks which are doubly linked lists, and reporters refer to their parents,) so it can't be directly represented in that way by JSON. Yet the JSON and the JavaScript objects used by Scratch when merely running to represent blocks aren't quite the same. (Both of these representations are particular to Scratch VM.) They can merely be represented by a tree. Even if it were helpful for IDs to be used when storing part of a project as JSON, for sharing structure, no such trouble would exist regarding a project merely open in Scratch.

Jonathan50 wrote:

…
Yet the JSON and the JavaScript objects used by Scratch when merely running to represent blocks aren't quite the same. (Both of these representations are particular to Scratch VM.) They can merely be represented by a tree. Even if it were helpful for IDs to be used when storing part of a project as JSON, for sharing structure, no such trouble would exist regarding a project merely open in Scratch.

Hey Jonathan50 I get what you're asking but I suspect nobody will be able to give you a satisfying answer. I'm guessing here but I bet the JSON id-linked representation is reused since it was already present and used (thanks to inheriting it from Blockly) and a cleaner runtime domain model which could be a tree simply has not been designed.

I agree with you about the benefits and suggest that in an ideal system there should be insulation between the serialisation format and the runtime object model. It's not the first time I've seen such leakage in a system and I suspect many people familiar with the code see additional work maintaining two models and keeping them individually encapsulated.

To be frank I'm not very familiar with the scratch-vm codebase although I have Blockly scars (old and somewhat faded). As an aside and based on your profile pic I hasten to add that Blockly's design seemed to tragically and senselessly preclude functional programming primitives in block languages. Not sure if that has changed in the past few years.

christo wrote:

Hey Jonathan50 I get what you're asking but I suspect nobody will be able to give you a satisfying answer. I'm guessing here but I bet the JSON id-linked representation is reused since it was already present and used (thanks to inheriting it from Blockly) and a cleaner runtime domain model which could be a tree simply has not been designed.

Oh! Blockly does attach IDs to blocks, though they aren't apparently used in such a way – using IDs to indirectly refer to things like blocks, variables, sounds, etc. when the obvious thing would be to directly refer to the JavaScript object.

I get the impression that this is a general implementation pattern across parts of Scratch though I now understand you're saying this is in contrast to how Blockly does it. Do you have any good examples of this in the Scratch source code you could point out so I can go check for evidence of whether my half baked theory holds?

christo wrote:

I get the impression that this is a general implementation pattern across parts of Scratch though I now understand you're saying this is in contrast to how Blockly does it. Do you have any good examples of this in the Scratch source code you could point out so I can go check for evidence of whether my half baked theory holds?

Each block stores the ID of its following block if any and preceding block or parent if any. A field may store the ID of a variable. See Blocks here. Here is how it might be used.

Scratch Render associates an ID with each drawable and skin, and Scratch VM asks the renderer to do things given particular IDs rather than asking the drawables or skins themselves. See here.

Thanks Jonathan50

christo wrote:

Thanks Jonathan50

Thank you…