Scratch-gui: Blocks - implement "item # of [string] in [drop down]" reporter

[thisandagain]

Implement new reporter as per discussions with the resources team. Essentially this reporter simplifies finding the index of an item in a list by it's value. In the event that multiple items in the list exactly match the supplied string the reporter will return the first index. In the event that no item exists that exactly matches the supplied string the reporter will return 0.

Block Spec

item # of [string] in [drop down]

Defaults

item # of [thing] in [list]

Drop-down

• [dynamic list of lists]

Position

The new reporter should be added to the data category below the item (drop down) of [drop down] reporter.

Reference

• Javascript
• Python

/cc @ntlrsk @carljbowman

[thisandagain]

Pushing to November milestone to match implementation timeline for lists.

/cc @rschamp @paulkaplan

[towerofnix]

This is actually really, really helpful, even for relatively more complicated projects :heart:

E.g. I could have three lists: "names", "x positions", and "y positions". Then I could get the x position and y position by doing something like this:

I can already do this by using a custom block (or some alternative method, like maintaining a list of references to the indexes of data), but this just makes everything a bit simpler.

[CosmicWebServices]

This is sweet

[mrjacobbloom]

Dictionaries here we come

[griffpatch]

I just wondered, what about the case where you have a list containing a
mixture of upper and lowercase versions of the same string.
If you ask for the index of one particular string and it matches exactly to
one, but only case insensitively to another, should it return the index of
the exact match? or always the first matching one?

On 11 August 2017 at 01:45, Jacob [e-mail] wrote:

Dictionaries here we come

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/LLK/scratch-gui/issues/600#issuecomment-321709756,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGbNvnJjzazPRMN06O5LSYdId6_9n7xPks5sW6QMgaJpZM4OyzIm
.

[thisandagain]

@griffpatch Good question. If we wanted to resolve that I suppose we would simply need to fully traverse the contents of the list looking for both exact and case insensitive matches before returning. The inconsistency here feels like it could be potentially confusing in either direction though so I'm not quite sure if I've formulated an option yet.

[mrjacobbloom]

Since scratch generally ignores case, I'd expect this block to be completely case-insensitive. That said, it'd be really handy to have another set of blocks that can be used to test case so we could do this manually if needed