# Any namespace or module in Snap?

If I import 2 libraries that both define foo what will happen?

(I did a forum & doc-pdf search before posting)

The second one wins. That's the right thing if, for example, you import a library, and then you find a newer version of the same library and you import that one. It's not the right thing if you imported the second library for the sake of some other block, but didn't want to lose the first version of FOO.

I once proposed a read-programmer's-mind feature that would remember the source of each block in the project so it could distinguish these cases, but Jens didn't want to make it complicated.

But he does occasionally make noises about wanting modules, so maybe something will eventually come of that.

Thanks.

• Would your mind-reader "source" be something like library url?

• Will current behavior be an issue as libraries increase?

• Are 2 blocks considered equal if their names + param-holes positions exactly match?

url, or something.

Not sure what the second question means.

I think they are asking what makes 2 custom blocks appear the same to Snap!

I don't think two instantiations of a block are ever equal. If you do

then

In other words, two blocks are equal only if they're identical (EQ?).

I'm stopping now as I'm completely failing to get what I think the OP meant and best just to wait for the OP

There are a blockSpec() and isGlobal attributes for custom blocks.
For , blocksSpec is "test %l %n".
Is considered different than "test %s %s" and local block.

That doesn't make sense. That's like saying 1 doesn't equal 1 but A which has the value of 1 is equal to A.

What about

Well, that's case insensitivity.

No.
That's proof that "equality" is just a convention and part of the language design.
Someone may design Domain-Specific Language where
1 == "one" if that suits its purpose.

I was not clear enough, sorry.

Say I have my own custom block f in the palette i.e. not an "instantiation".

I import a library that contains a custom block f.

Both have some holes with some shapes. What rules of sameness determine whether I end up with 1 vs. 2 custom blocks in my palette. Same question if I import a newer version of the lib, or import a different lib.

I think @dardoro might have answered, but would like to confirm.

I expect this to become an common question (and possibly an issue) as people start using libraries freely.

It replaces the old block with the new one if the text and the inputs of the block are the same. The script inside gets replaced. If not, it creates another block.