When a sprite is renamed, update all the times it’s used (rename all)

You could get a pointer to a sprite with untitled script pic (2) for example. And you could keep a global list of those references.

That could work but to identify a list item you need the number that item is, basically just turning it into a name, I can make a demo using this idea and dictionaries tho!

What we’re doing is basically replacing sprites with OOP

Actually I don’t know how to handle the order of sprites because “ask my stage for my other sprites” reports them in layer order and that will break everything

I’m close, along the way I found out something

The reason snap references variables for lists, if you are confused here’s some examples!

untitled script pic 76

Is because otherwise you wouldn’t be able to edit something like this

Originally I thought this was for making things faster, and was actually making stuff harder. While it does make some things harder by turning them into juggling situations. This is an extremely creative way of correcting this problem without just making the block do something special like that

I'm not sure what you mean by this. Do you mean "if you assign a list to a variable, the actual value of the variable is a pointer to the list"? That's true, but there's nothing special about variables or about lists in that, really.

Like all dialects of Lisp, Snap! really has only one data type, namely pointer. Whenever you refer to any value, you are implicitly dereferencing that pointer. It's just that you can't really notice this, as a user, except for lists, because lists are mutable. (Actually, no, sprites are mutable too, and when you refer to a sprite as a value, you are dereferencing a pointer. It's just that nobody expects anything else. That is, if you say

nobody is surprised that the value of FOO isn't a new copy of the old sprite. If we had a
untitled script pic (3)
primitive, then the same issues would arise for strings.)

And as for variables, any expression whose value is a list can be used as the list input to the list mutation commands; there's nothing special about using a variable as the expression.

And yes, the main purpose is speed, especially these days when we have bitmaps and other such huge data structures in lists. You wouldn't want to copy those things every time you use one as input to some procedure.

It's not special to snap, in fact it's normal. Linked lists are in practically every programming language. JavaScript, Python, Java, C++, all use linked lists. Ok, technically they are just pointers to the list, just like in snap, but it's still the same.

I didn’t know that actually!
It was just an interesting observation I saw

yeah im pretty sure its just scratch trying to make datatypes easier to understand

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.