Consider limiting the Makey Makey extension's number of key sequences

[ericrosenbaum]

The current behavior of the Makey Makey extension's when keys pressed in order block is that any sequence it checks for gets added to the object this.sequences, which is checked on each key press. You can drop a variable onto the hat block containing a custom sequence, and it gets added to this.sequences.

@rschamp pointed out that sequences are added but never removed. This creates a potential memory and performance problem, in the situation where many sequences are added.

Because the sequences are added on the tick (i.e. by the hat opcode), they can't be added at a rate of more than a few hundred per second, but this could still add up. Note that a sequence is only added if it is a string which can be split on space characters into at least two values, and if it is unique. Here's an example that adds 30 sequences per second:

So the questions include:

• Is this enough of an edge case that we don't need to worry about it?
• What logic could we use to remove sequences automatically, when they are not in use?
• If the above is not straightforward (I can't think of a way to do it), should we impose an arbitrary limit on the number of sequences? They could e.g. be in a buffer, so that old ones are removed as new ones are added, and the buffer could be quite large without trouble (e.g. 100)

[benjiwheeler]

I think it's important to limit this functionality now, before anyone uses it. Otherwise, we might be stuck supporting it forever!

Could the last sequence used by this hat block be stored as a property on it, and then when we evaluate it to add a new sequence, we first remove the old one from this.sequences? Or, could the values we store in this.sequences contain a reference or id that points back to the hat that created them, and when we add new ones we iterate through the list and remove old ones first?

[ericrosenbaum]

@benjiwheeler re: limiting it now, I think any limit we place on it will be non-onerous (e.g. would only break a project that uses more than 100 unique sequences... which maybe will never happen anyway?)

re: storing references to hats etc., in general the extensions do not access properties of blocks themselves, and that is probably good for future compatibility. It might be worth considering though!