If every block had a specific ID, based on the label, but camel cased, we could allow multiple custom blocks to have the same labels. The (2), (3), (4), (etc.) would be attached to the ID of the block and can be edited by right clicking the block template in the editor, and clicking an object. Would be really cool!
Hmm, what happens if you change the title text? Does the ID change too? I see problems either way. And if you mean that version numbers would become invisible without right-clicking, I can see why you want that--I get annoyed by version numbers sometimes too. But I also see problems with it, if users can't discoverably know which block is being used in some script.
And camel case is beyond hideous and should never have been invented. There's no reason it couldn't be title cased! I think that would be a slight improvement over using the block's label in the "Lisp code" feature. (Although on second thought, you couldn't distinguish "foo %a bar %b" from "foo %a bar" that way.)
I tried changing one of the slot names. The version number still appears unfortunately.
We could still allow version numbers, just with a few restrictions.
They could be added by default, but we can remove them. [This can be toggled in settings]
The version number will appear if the labels are the same,
regardless of the block type, slot type or slot name.
So if you try to make this:
testing [123] testing (123) testing <t>
You still end up with this:
testing [123] testing (123) \(2) testing <t> \(3)
And about the ID, IfNotCamelCasedLikeThis, maybe_seperated_by_underscores_like_this.
Actually, this is not the case. Once you duplicate a block, the version number is part of the label - you just have to delete it after changing slot types.
Correct.
I don’t t see the point of it? You just can rename it so you know which one is which.
yes, but you see not only does the version number ignore input types and input names, but also the seperators of slots.
this technically means the blocks:
( () + () @delInput @addInput ) ( () × () @delInput @addInput )
arent even following snaps own rules
But they still work as intended to? Right?
That's not camel cased; it's title cased. Camel cased would be if the "If" had a lower case "i." Title casing isn't so horrible.
sorry. got them mixed up.
:~)
I have to admit, though, there are other species of camel in which the head rises higher than the humps.
amazing demonstration
Yes they are? They have different labels.
There is no "version label", it's just what you get when you duplicate a block, like copying a file on a computer into the same directory as the original. This is just part of the label, and can be removed.
what im trying to say is that the id should be different from the label text itself
so when this block is duplicated the id changes and not the label text
here are different solutions for things you might ask about:
1. what if i duplicate a block?
so lets say you are making a block and the label is 'test block'
the 'id' should be title cased 'testBlock'
when this block is duplicated, the id changes to 'testBlock2'
while the label 'test block' stays the same
2. what about symbols that cant be in an id?
if a block is made that has a label like this 'test thing ^-^'
the characters in ^-^ are prohibited in an id, so they are removed.
this turns 'testThing^-^' into 'testThing'
this also happens to numbers
3. does the label account for slots and icons?
it does.
when i make a block like this 'block %slot $icon-2-55-76-243'
the numbers and symbols are removed 'block slot icon'
then they are title cased 'blockSlotIcon'
That's "TestBlock"! 
But why does there need to be an ID? For what use case do you need two completely identical blocks?
got them mixed up again.
I'm not @theaysnap, but for me, it's always a minor annoyance that "Duplicate block definition" puts that "(2)" in the title text, even though the very first thing I do is change the rest of the title text to something entirely different, and I have to go to the (slight) trouble to delete that text. So it'd make me a little happier if Snap! didn't add the "(2)" unless it's still necessary on closing the Block Editor. (Or maybe have the "(2)" but automatically delete it when closing the Block Editor if the title text has become unique.) But I agree with you: there's no case in which I want two exactly same-looking blocks that do different things; that's just asking for bugs.
i agree very much
well thats the whole point of this post.
blocks would be identified by id instead of text.
if the labels are the same, theres no bug
if the id is the same, there would be a bug, but in that case, add a letter of number afterward to avoid this.
the point of this post was for a project.
two blocks could have the same label, but the slots were different.
but unfortunately the "(2)" is still added to the label text, since it doesn't account for slots, so they wouldnt be identical
and, who knows, someone could use this to their advantage.
