Fixed multimap

As we discussed multimap issue with not having indexes and lists, me and my friend liava improved the block to have them.


Original block:
untitled script pic (90)

Improved block:
untitled script pic (92)
untitled script pic (95)


ANOTHER version of improved block, firstly i wanted it to be separate like this:
untitled script pic (97)

untitled script pic (98)

But then i thought, since multimap already exists, they could be just combined to this:
untitled script pic (100)


What do you think?

No info

@bh bump
this guy wants his (slower but better)block to become a standard library

it is not better, it is CORRECT one, instead of broken one

My 2 cents :slight_smile:
AFAICT, the current multimap works perfectly when the number of supplied lists matches the number of parameters in the function

If this isn't true then it is broken

The case of what it should return if the numbers don't match up, is up to who ever defines the behaviour of the block

There are quite a few blocks that don't return what I'd like when pushed beyond their intended use but I don't consider them to be wrong - I just accept their current behaviour and if needs be - make a modified version of them with a different name -i.e. enhanced multimap

no.

No to what part of my post?

all.

maybe you should describe in a more detailed post rather than just saying one word? I'm really confused on what you're talking about

it is obvious that i don't think it should be added as another block, it should be replaced.

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