Case Sensitivity Options

EIephant_Lover

I thought I made a post like this before, but I couldn't find it anywhere.

I know there are SIMILAR topics but this is not the same.

I'm suggesting that on blocks such as [] = [], [list] contains [thing]?, etc., where case sensitivity may or may not matter, the blocks have a little gear/settings icon in which there is a little box that says “Case sensitive?” with a checkbox. You can do this to edit whether something reports based on case sensitivity or not. For example, if the box was unchecked, <a=A> would report true. However, if it was checked, it would report false, but <A=A> would report true.
Here's what the block with the settings would look like:

<⚙️  [] = [] :: operators>

Here's a mockup of what the box would look like:

Sorry for the poor quality image, I made it quickly.

Please note this would work with ALL blocks that can vary based on case sensitivity.

Also, MIT's AppInventor 2 has little settings buttons for expanding blocks, so that's kind of where the design idea came from.

I'm well aware there is a “workaround”. But it doesn't make sense that you would have to change case sensitivity based on the fact that some blocks are and some aren't. Plus, the workarounds involve either added lots of costumes or variables, or editing the JSON of blocks.

Another idea is the simple addition of one block:
[scratchblocks
<case sensitive<>::operators>

Basically, if you did

<case sensitive<[A] = [a]>::operators>

it would return false, but if you did it without the block, or put

<not<case sensitive<[A] = [a]>::operators>>

it would return true.

By default everything would not be case sensitive.

Edit: Doesn't seem to work with how Scratch handles booleans.

Last edited by EIephant_Lover (Aug. 20, 2019 00:30:01)

TenType

Well, there are some scripts that can do case sensing like the scripts shown here.

Last edited by TenType (July 13, 2019 22:25:47)

EIephant_Lover

TenType wrote:
Well, there are some scripts that can do case sensing like the scripts shown here.

Yes, but not even near all, and you don't have the option to make them case sensitive or not.

hellounicorns2

I support! It would make making projects with lots of words involved much easier and the current workaround isn’t exactly straightforward.

TenType

EIephant_Lover wrote:
TenType wrote:
Well, there are some scripts that can do case sensing like the scripts shown here.
Yes, but not even near all, and you don't have the option to make them case sensitive or not.

You could easily make the scripts togglable whether to do case-sensing or not.

EIephant_Lover

TenType wrote:
EIephant_Lover wrote:
TenType wrote:
Well, there are some scripts that can do case sensing like the scripts shown here.
Yes, but not even near all, and you don't have the option to make them case sensitive or not.
You could easily make the scripts togglable whether to do case-sensing or not.

“Easily”.

It is not easy to make a complicated string of blocks simply to know whether something is case sensitive. Not for me, at least. Sure, once you've figured out all the scripts and exactly what they do, you can add on to it, but the beginning part is not easy. And besides, this isn't even a new block suggestion.
I know there is a workaround. It doesn't mean that this wouldn't be a really helpful addition. Why would they change the layering blocks? You could make a variable and change it based on the layer and make it go to front and then back so many layers and blah blah blah, but they added a new block for convenience. One of the reasons I suggest things like this is because it makes programming easier. I love to program and figure things out, yet I hate tediously doing the same code that I already know what it does.

Sorry for that rant. Anyway, I'm suggesting they add a toggle option, that's all. I don't think that case sensitivity should be something that needs a workaround based on the variability of which blocks are case-sensitive and which are not.

TenType

EIephant_Lover wrote:
TenType wrote:
EIephant_Lover wrote:
TenType wrote:
Well, there are some scripts that can do case sensing like the scripts shown here.
Yes, but not even near all, and you don't have the option to make them case sensitive or not.
You could easily make the scripts togglable whether to do case-sensing or not.
“Easily”.

It is not easy to make a complicated string of blocks simply to know whether something is case sensitive. Not for me, at least. Sure, once you've figured out all the scripts and exactly what they do, you can add on to it, but the beginning part is not easy. And besides, this isn't even a new block suggestion.
I know there is a workaround. It doesn't mean that this wouldn't be a really helpful addition. Why would they change the layering blocks? You could make a variable and change it based on the layer and make it go to front and then back so many layers and blah blah blah, but they added a new block for convenience. One of the reasons I suggest things like this is because it makes programming easier. I love to program and figure things out, yet I hate tediously doing the same code that I already know what it does.

Sorry for that rant. Anyway, I'm suggesting they add a toggle option, that's all. I don't think that case sensitivity should be something that needs a workaround based on the variability of which blocks are case-sensitive and which are not.

Anyways, I still support. It would be somewhat convenient to use.

EIephant_Lover

-snip-

TenType wrote:
Anyways, I still support. It would be somewhat convenient to use.

Thanks

I kind of exploded XD

EIephant_Lover

Bump!

mr_coolcat

I can see that to be useful and I know there's a script of how to do it but for beginners of Scratch will find it a bit difficult to understand.

I support that idea.

EIephant_Lover

mr_coolcat wrote:
I can see that to be useful and I know there's a script of how to do it but for beginners of Scratch will find it a bit difficult to understand.

I support that idea.

Thanks

Sheep_maker

Hiding the option in a settings dialog (which is a featured supported by Blockly, the block rendering engine Scratch uses) makes it harder to see from a glance whether it's case-sensitive or not

A different suggestion called for a separate block,

<[A] is exactly [a]?::operators> // false

which I think could work.

EIephant_Lover

Sheep_maker wrote:
Hiding the option in a settings dialog (which is a featured supported by Blockly, the block rendering engine Scratch uses) makes it harder to see from a glance whether it's case-sensitive or not

A different suggestion called for a separate block,
<[A] is exactly [a]?::operators> // false
which I think could work.

I think having a setting would be better. I've seen the block suggestion, but it would be much easier to have settings so that if I wanted to know for sure for example if a list contains “A”, not “a”, then I could use

<⚙️  [list v] contains [A] ? :: list>

And make it case-sensitive, instead of making more blocks to work around it.

LuckyLucky7

Support, this suggestion make things make more sense, since there is an obvious difference between the letter ‘A’ and ‘a’(although they are the same letter, one of them is uppercase and the other letter a lowercase letter). Plus, an option would be useful, because the current workaround for this suggestion is complicated and hard to understand(unless you are @griffpatch

).

Last edited by LuckyLucky7 (Aug. 8, 2019 23:18:23)

gamebeater187

I support, because it is extremely hard to find a workaround and New Scratchers would be lost if they needed case-sensitivity.

EIephant_Lover

Bump!

Testingscratcher

sigh… anyway, what I was going to say is that this block…

<case sensitive <[Apple] = [apple]>::operators>

… is not possible. Let's start with the expression, “Apple” = “apple”. In Scratch, this is true, so let's take this value of true and stick it in the case sensitive boolean… what does it do then?

This block, on the other hand…

(case sensitive ()::operators)

… might be able to work, if string inputs are edited (and I'll experiment with this in my fork of the Scratch repositories) so that they instead take and use two arguments at once: the string itself, and whether or not it should check for case sensitivity, which would default to false. Adding this reporter block would then contain the second argument true as an input, and override the default value already contained in the block beneath it.

As for this other variation of that block, the one with the gear… I semi-support it, mostly because there are more blocks which have to be edited to properly support this feature, and it won't work correctly inside a reporter block (e.g. (item # of (thing) in (list v)) due to reasons I mentioned above.

Last edited by Testingscratcher (Aug. 19, 2019 16:45:20)

EIephant_Lover

Testingscratcher wrote:
sigh… anyway, what I was going to say is that this block…
<case sensitive <[Apple] = [apple]>::operators>
… is not possible. Let's start with the expression, “Apple” = “apple”. In Scratch, this is true, so let's take this value of true and stick it in the case sensitive boolean… what does it do then?

This block, on the other hand…
(case sensitive ()::operators)
… might be able to work, if string inputs are edited (and I'll experiment with this in my fork of the Scratch repositories) so that they instead take and use two arguments at once: the string itself, and whether or not it should check for case sensitivity, which would default to false. Adding this reporter block would then contain the second argument true as an input, and override the default value already contained in the block beneath it.

As for this other variation of that block, the one with the gear… I semi-support it, mostly because there are more blocks which have to be edited to properly support this feature, and it won't work correctly inside a reporter block (e.g. (item # of (thing) in
) due to reasons I mentioned above.

It would still work.

I don't understand why you think it wouldn't; could you make some Scratchblocks so I can see what you're saying?

As for the second block, what would this:
```
(case sensitive [Apple]::operators)
```
even mean? Sorry, I don't seem to understand your explanation. What would it return? True? False? Apple? Or something else?

Last edited by EIephant_Lover (Aug. 19, 2019 16:50:49)

WindOctahedron

Support - case sensitivity is sometimes needed, and sometimes not - and making it optional would encourage experimentation and creativity.

Testingscratcher

EIephant_Lover wrote:
It would still work.

I don't understand why you think it wouldn't; could you make some Scratchblocks so I can see what you're saying?

I thought my first explanation would be simple enough, but I guess I have to go into further detail…

<case sensitive <[Apple] = [apple]>::operators>

Blocks go in order from in to out. Therefore, the first block would be this.

<[Apple] = [apple]>

The way the Scratch code functions, as I have discovered, is that it converts each string to lowercase anyway before the comparison even happens. But let's disregard that for now. Suppose it's simply case insensitive. This block takes two strings, and spits out a boolean through comparison. “Apple” is an input, and “apple” is an input. Scratch's cast function deems this comparison to be true. Therefore, true would be the output of this block.

Now let's move on to the second block. It is this suggested block.

<case sensitive <true::operators>::operators>

As you can see, I have already substituted the input parameter with the one returned from the first block. Now, from what I can tell, this block is taking “true” and trying to determine whether or not it is case sensitive. It does not utilize either of the inputs of the equal comparison block. Not to mention, what within the block is trying to determine case sensitivity? Sure, a new cast function could be added, which is what I did (and I'll explain that down below), but the equal comparison block is spitting out only one value, technically a string and not the value the user wants to have checked.

EIephant_Lover wrote:
As for the second block, what would this:
(case sensitive [Apple]::operators)
even mean? Sorry, I don't seem to understand your explanation. What would it return? True? False? Apple? Or something else?

This block, on the other hand, I have coded a little differently. It outputs an object instead of a string, and that was admittedly the best way I could come up with to feed both normal strings and the output of this block through a new cast function which does make a string explicitly case sensitive. It's set up so that if the input of that function is the object, outputted only from this new block, then it extracts the string from the object and returns the string with typecase left intact. If it's just a string, then return a lowercase (case insensitive) version of that string.

And the thing is, sticking a variable block in this case sensitive block returns the string which the user wants to have case checked! The only downside I guess is that, in a comparison such as <(txt) = (txt)>, you have to have the case sensitive block on both sides. Otherwise you're comparing a string which is case sensitive with one which isn't.

<(case sensitive [Apple]::operators) = [Apple]> // returns false because the second "Apple" is cast to lowercase "apple"
<(case sensitive [Apple]::operators) = (case sensitive [apple]::operators)> // returns false; case sensitivity function deems the strings to be different
<(case sensitive [Apple]::operators) = (case sensitive [Apple]::operators)> // returns true; case sensitivity function deems the strings to be identical

Need I say more?

Last edited by Testingscratcher (Aug. 20, 2019 00:30:54)

Discuss Scratch