Custom Block With a Primitive's Selector Can Replace Primitive in Script Pics

[mark4sisb]

Alright, after a bit of research, I think I understand what is going on here. Firstly, customized primitives aren't supposed to be saved with script pics (something I'd forgotten, but I think it's a good thing):

@jens

That's right, and that's - for now - on purpose. Single blocks, scripts and script pics don't include customized primitives, but instead reference them by name only. That way importing them into another project will not change the target project's primitives. This is kind of a big deal, so looking at someone else's code doesn't change your project in ways that you can't easily track let alone undo.

The selector of the block is what identifies it when saving/loading if it has a selector. By looking at the XML, I discovered that this test:

@ego-lay_atman-bay

I did also test to see if it was the selector of the duplicated block that was the issue

probably didn't work. You see, for whatever reason (there is probably a good reason, I just don't know it), when setting the selector of the block to nothing, this change isn't saved. If you change the selector to something other than an empty text string, then trying to import a script pic of that block completely fails. Moreover, if you set the selector to an empty text string using metaprogramming, things behave as expected. The primitive definition is lost, but the custom block remains.

Therefore, when the script picture is saved, it has this custom block which has a selector that is the same as the primitive, and the primitive edits aren't included. When the image is imported, Snap! doesn't see the edited primitive, but it does see a custom block that looks like an edited primitive. The custom block is lost and the primitive is replaced, creating the effect described.

This leads to two things:

Firstly, I would propose that "duplicate block definition" should not duplicate the selector. As far as I know, the selector is not something that end users are supposed to be using anyways. This would fix this issue and make what is going on a whole lot more understandable.

Secondly, by using this bug, one can get around this:

@jens

looking at someone else's code doesn't change your project in ways that you can't easily track let alone undo.

Here's how:
Don't bother with the primitive other than duplicating the definition. The script pic won't save it anyway. Now that you've duplicated the definition, take this new block and make the modifications you want to have in the primitive. If you need a dependency, make that by hand (not by duplicating). Here is an example of this in action:

The first block is the primitive, the second is the custom block which houses the modification you want to the primitive, and the last is the dependency.
This is clearly a bug, especially because you (@jens) specifically designed script pics not to work this way. Even if you change the behaviour of "duplicate block definition", this still can be achieved by manually changing the selector. I would recommend patching this.

PS: I had also tried editing the selector to see if that helped, but got bitten by

@mark4sisb

when setting the selector of the block to nothing, this change isn't saved

so I didn't think that it could possibly be a same-name conflict:

@jens

Instead you could pose this as a question ("how are you dealing with this weird way of same-name-conflicts that no other programming language allows but that I somehow want to use in Snap!, hmmm?")

But apparently it is, and you probably knew enough of what was going on to know this too. I'm sorry, but I really had tried to my wits' end to make sure that this wasn't a same-name-conflict.