This would be a boolean block, so it's green, but with pointed ends, and goes in the operators section:

< [word]  contains  [a letter v]  :: category operators >

EDIT: when I saw this topic surprisingly re-emerge today (Dec.17th), I had an idea for an alternative wording:

< [word]  has  [a letter v]  in it  :: category operators>

Is that harder to misunderstand, so fixing some of the original questions I raised below…?

It can take a variable in the left slot, and the right slot is a drop-down menu with the items:
- a letter (this can refer to either upper or lower case)
- a number (or “a digit”?)
- a capital letter
- a small letter
- only letters
- only numbers (or “only digits”?)
- only capitals
- only small letters

But you can also drop a variable into the right ‘slot’ (like you can for many other such drop-downs), to give a more generic test for substring within string:

< [word]  contains  (substring) :: category operators>

EDIT: or (with the new, alternative wording):

< [word]  has  (substring)  in it :: category operators>

Questions:
1. Is it OK to miss out “a” before some of the drop-down items? I can see the possibility that “word contains a letter” could be misunderstood as asking if it contains *only* a single letter…? But saying just “word contains letter” sounds slightly odd too…
2. Is it a bit too ‘technical’ to use “upper/lower case” instead of “small/capital”?
3. Similarly to above two, is “a number” ambiguous in meaning (i.e. could be asking if it's a numerical value rather than a string), but saying “a digit” is a bit too ‘technical’?
4. Any other possibilities for the drop-down? (It's already quite a lot, I think, so I'd rather not add things like “alphanumeric”…!)

Any takers?

EDIT: one of the reasons I came up with this block is to bring back case sensing (which is now AWOL from Scratch –well, nearly: of course, we managed to find other… ways… around… it…) The other things (e.g. substrings) have workarounds, but they are still mind-numbingly tedious, so I thought it was quite useful to have them rolled into it.

Technically already possible- it's just the the workaround is a humongous pain in the rear.

Therefore, full support.

+10

Support, and great way of wording it.

Support!

Hmmm, continuing from my other topic bump, I don't particularly like topics getting ‘bumped’ so often.
Been a week since I touched this and the other…

Going back on-topic, I have realised there's a potential issue with the way the drop-downs-that-take-a-variable work that might mean implementation of this isn't so easy. But I suspect it's still not really that hard, so it seems a worthwhile thing to add, I think…

First, +1, great suggestion. I'm not sure how often I would use this block, but it has great potential.
Second, would it be possible to use a dropdown similar to that in list blocks, so that it has selectable options but it also accepts text and variables?

Not too much support.

It is a good suggestion to fix the problem that the normal operators of =, <, and > do not consider case.

I would have preferred proper case handling all over Scratch but you can't do that without breaking old code.

Interesting to see this re-emerge…

Had an idea for an alternative wording for the block - rather than “contains”, use “has … in it” instead.

Here's what it then looks like for each of the possible dropdown selections (at least, the ones I suggested):

< [word]  has  [a letter v]  in it > // category=operators
< [word]  has  [a digit v]  in it > // category=operators
< [word]  has  [a capital letter v]  in it > // category=operators
< [word]  has  [a small letter v]  in it > // category=operators
< [word]  has  [only letters v]  in it > // category=operators
< [word]  has  [only digits v]  in it > // category=operators
< [word]  has  [only capitals v]  in it > // category=operators
< [word]  has  [only small letters v]  in it > // category=operators

And with the variable put into the dropdown:

< [word]  has  (substring)  in it > // category=operators

It's a touch longer, but is it better? - In particular, less likely for the meaning to be misunderstood?

Yes, I can see how this could be helpful…
But I don't know if having the substring detector in the same block would work out so well. After all, what if you were looking for “a letter” in the string and it instead looked to see if the string had any letters in it?

I think I would support.

AonymousGuy wrote:

…what if you were looking for “a letter” in the string and it instead looked to see if the string had any letters in it?

Yes, indeed - that's what I was thinking about when I mentioned the implementation issues above.

But Scratch does know when there is a variable in a slot (looking at the raw json, there is a clear difference), so I'd think it should be possible to implement it to follow a distinct path when it's a variable versus when it's a selection from the drop-down menu… (I guess it's fairly unlikely a Scratch dev would read this and confirm/deny that's the case…?)

Sounds great to me - but isn't this already -theoretically- possible? It would be incredibly annoying, but possible?
But yes, 100% support.

-Supreme

These two options could also help:
- a punctuation mark
- only punctuation marks
The substring detection would also be exceedingly useful.
I support this idea.

What's the best way to do this at present?

In what I'm coding, the player is asked for their name, and I want to be able to check to see if they enter a particular name… except that there are multiple ways to spell it. So I could just have it check a list that's populated with every spelling I can come up with, but it would be far nicer to check if the first syllable is one of three options and if the last syllable is one of five options (and just ignore any gibberish in between). Is this latter method feasible at present?

jlashwell wrote:

What's the best way to do this at present?

In what I'm coding, the player is asked for their name, and I want to be able to check to see if they enter a particular name… except that there are multiple ways to spell it…

Wow, forgot to reply to this… (I guess it's kind of asking for script help, really, too.)

Yes, I think your suggestion (using a list with all possible spellings) is probably the easiest/quickest you're going to come up with, provided there are not loads of possible alternatives, and provided there are not loads of different names (each having alternatives) that you want to check for.

Part of the reason this is likely to be your best option is because you only need to check if a string is any one of the alternatives, rather than finding which specific alternative it is - and Scratch provides exactly that functionality in:

< [list v]  contains  [string] >

In particular, because it's a single block that gets translated into a lower-level code, this is actually *really* fast (for Scratch) - it's faster than even implementing a binary search within Scratch to search for an item in an ordered list!


However, there is a potential drawback: if you have different names you want to check for (each having its own set of alternative spellings), then you will need a list for each possible name-set. If there are lots of such names, then it'll be too many lists to be practical, I suspect.

If that's the case, I can only suggest that you implement some kind of matching syntax for your possible alternatives. (For example "Al*[ae]n" would mean there can be any number of letter Ls because of the asterisk after it, and the second-to-last letter could be either A or E.)

It'd be really tedious to do such a thing with Scratch, because of its limited string manipulation (you'd have to check letter-by-letter, with lots of branches for different cases of ‘special’ characters that mean particular syntax), so you would only do such a thing if you really have *loads* of possible names with lots of alternatives…

I figured this out on my test account. You can search for a substring within a string, and receive the position(s) at which it occurs (if at all). http://scratch.mit.edu/projects/20737186/

Support. I definitely need this.

how about

<[word] contains [letter v]> 

I'd prefer

<[string] contains [a letter ▼] :: operators> //Bad fake dropdown thingy that you can type stuff in

so you can type strings into the second menu.