Discuss Scratch
- Discussion Forums
- » Suggestions
- » Case Sensitivity Options
- EIephant_Lover
- Scratcher
500+ posts
Case Sensitivity Options
I was working on a project which included a typewriter as well as the translate feature.
I translated “hello” to Spanish, and my typewriter appeared with the character I have chosen to show when a character is not supported then “ola” (“⍰ola”). I took out the translator function and noticed it changed “hello” to “Hola” and not “hola”.
My project uses lowercase letters as names but shows uppercase letters (which doesn't matter).
So, I suggest that Scratch should have a case sensitivity option. Above the scripts and below the stage (where sprite options are placed), there should be a “Case sensitive?” check box that when turned on makes all lists or names (especially in booleans) case sensitive when checked, and, of course, not when not checked. For example:
Do you see what I mean?
TL;DR: Scratch should add a Case Sensitivity option that allows you to change a sprite's decision based on whether a letter is capital or not.
Thanks for viewing and considering!
(If you didn't figure it out, case sensitivity is like when something matters if you didn't capitalize, e.g. Scratch usernames when entered aren't case sensitive but passwords are. Case being like upper- and lowercase.)
An alternative:
I translated “hello” to Spanish, and my typewriter appeared with the character I have chosen to show when a character is not supported then “ola” (“⍰ola”). I took out the translator function and noticed it changed “hello” to “Hola” and not “hola”.
My project uses lowercase letters as names but shows uppercase letters (which doesn't matter).
So, I suggest that Scratch should have a case sensitivity option. Above the scripts and below the stage (where sprite options are placed), there should be a “Case sensitive?” check box that when turned on makes all lists or names (especially in booleans) case sensitive when checked, and, of course, not when not checked. For example:
<(item (1 v) of [my list v] :: list) = [apple]>Say that item one was “Apple”, not “apple”. If the case sensitive box was checked, then the result would be “false”. If it weren't the result would be “true”.
Do you see what I mean?
TL;DR: Scratch should add a Case Sensitivity option that allows you to change a sprite's decision based on whether a letter is capital or not.
Thanks for viewing and considering!
(If you didn't figure it out, case sensitivity is like when something matters if you didn't capitalize, e.g. Scratch usernames when entered aren't case sensitive but passwords are. Case being like upper- and lowercase.)
An alternative:
I'd {like to} see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).
Last edited by EIephant_Lover (Jan. 25, 2019 17:55:39)
- _nix
- Scratcher
1000+ posts
Case Sensitivity Options
Hmm… personally, I think your issue is a really specific use-case. The problem is that switching between costumes is case sensitive, right? So in this case, I think you'd be better off with a more simple “to (lowercase/uppercase)” block. That way, in your typewriter project, when you do “switch costume to..”, you can just attach a “to (lowercase)” (or uppercase) block to “(letter (N) of (string)”.
A global toggle (well, per sprite, but still effectively limiting whether ALL scripts are or are not case sensitive) just doesn't seem very useful to me. I'd personally rather see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).
A global toggle (well, per sprite, but still effectively limiting whether ALL scripts are or are not case sensitive) just doesn't seem very useful to me. I'd personally rather see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).
Last edited by _nix (Jan. 24, 2019 01:24:49)
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- -Accio-
- Scratcher
1000+ posts
Case Sensitivity Options
Support!
This would be convenient for a lot of projects which include variables and operators. You could make more precise inputs, outputs, and statements, which would be really useful
This would be convenient for a lot of projects which include variables and operators. You could make more precise inputs, outputs, and statements, which would be really useful
Hi There! I'm -Accio-
I am currently attending university for a Bachelor's of Science in Chemistry.
“If you are not part of the solution, you are part of the precipitate”
- EIephant_Lover
- Scratcher
500+ posts
Case Sensitivity Options
is case sensitive, right? So in this case, I think you'd be better off with a more simple “to (lowercase/uppercase)” block. That way, in your typewriter project, when you do “switch costume to..”, you can just attach a “to (lowercase)” (or uppercase) block to “(letter (N) of (string)”.Thanks for the feedback However, I wasn't asking for help on my specific project, and it was actually more toward the list case sensitivity than the costumes I suppose. The block ideas are also cool, I'll update my original post to include that (with credit to you, of course)! Hmm… personally, I think your issue is a really specific use-case. The problem is that switching between costumes
A global toggle (well, per sprite, but still effectively limiting whether ALL scripts are or are not case sensitive) just doesn't seem very useful to me. I'd personally rather see an extension which adds case-sensitive blocks, such as “case sensitive (A) = (B)”, alongside that “to (case)” block for use when you explicitly don't want case to matter (like in switch costume).
- _nix
- Scratcher
1000+ posts
Case Sensitivity Options
Oh, gotcha – yeah, an extension would need to have a “case sensitive item # of (x) in (list)” block, but…ew, y'know? That's super verbose. I can see why your idea would at least make that code look cleaner - it'd just be the ordinary “item # of (x) in (list)” block… however, they say explicit is better than implicit. When you see that block, you Thanks for the feedback However, I wasn't asking for help on my specific project, and it was actually more toward the list case sensitivity than the costumes I suppose.don't know how whether it is going to act case-sensitive or not, until you also see the state of the toggle for “is this sprite case sensitive?”. And I wonder if that could cause confusion to people reading the code.
(PS: What if for some reason you initially decide you don't want a sprite to be case sensitive, but then later you decide you do want it to be – and by that point, you'd forgotten the reason you wanted it to not be case sensitive, or even that you made that decision at all! So then the older scripts, which relied on it being not case sensitive, would suddenly be broken, which could be difficult to debug. Just an interesting situation to consider.)
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- EIephant_Lover
- Scratcher
500+ posts
Case Sensitivity Options
-snip-
Or maybe we could just do it on lists and variables, and have a “Case sensitive?” checkbox when making the list in the first place (as the cloud variable checkbox is).
So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.
don't want a sprite to be case sensitive, but then later you decide you do want it to be – and by that point, you'd forgotten the reason you wanted it to not be case sensitive, or even that you made that decision at all! So then the older scripts, which relied on it being not case sensitive, would suddenly be broken, which could be difficult to debug. Just an interesting situation to consider.)That's true. This, I suppose could be very confusing to younger Scratchers. Perhaps we could simply include the “case sensitive” blocks you were talking about, maybe as an extension, so you can do different things to different scripts. (PS: What if for some reason you initially decide you
Or maybe we could just do it on lists and variables, and have a “Case sensitive?” checkbox when making the list in the first place (as the cloud variable checkbox is).
So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.
<(item (1 v) of [list v] :: list) = [Apple]>Output is true.
<case sensitive<(item (1 v) of [list v] :: list) = [apple]> ::operators>Output is false.
<not <case sensitive <(item (1 v) of [list v] :: list) = [apple]> ::operators>>Output is true.
Last edited by EIephant_Lover (Jan. 25, 2019 18:05:14)
- _nix
- Scratcher
1000+ posts
Case Sensitivity Options
Ooh, this is something I was thinking about! I think it would be better to have a block like this: So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.<(item (1 v) of [list v] :: list) = [Apple]>Output is true.<case sensitive<(item (1 v) of [list v] :: list) = [apple]> ::operators>Output is false.<not <case sensitive <(item (1 v) of [list v] :: list) = [apple]> ::operators>>Output is true.
<case [sensitive v] <(item (1) of [list v]) = [Apple]> :: operators booleans>
<case [insensitive v] <(item (1) of [list v]) = [Apple]> :: operators booleans>
That way we aren't messing with logic blocks.
That said, I'm sort of clueless on how one would actually implement this – obviously Scratch has never had any blocks like it. It would be, “first set a flag that the contained blocks should be executed case-sensitively (or not), then execute the contained blocks”; but as far as I can tell, Scratch block inputs are always executed before they're passed to the containing block. So I don't know if this would be possible with Scratch's code. But I think it would be pretty neat!
Oh yeah, one minor issue with it – suppose you want to stick “item #” into it? Then you'd get this (for example)..
say <case [sensitive v] (item # of [Apple] in [list v] :: list) :: operators booleans>
We'd probably need two blocks – one for round-shape reporters, the other for boolean reporters. And that feels a little like a kludge to me, since they'd have exactly the same behavior, just different shapes.
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- Monniasza_spzoo
- Scratcher
100+ posts
Case Sensitivity Options
Possible blocks:Ooh, this is something I was thinking about! I think it would be better to have a block like this: So, this is what it would be like. The first blocks shows that item one of the list is indeed “Apple” rather than “apple”.<(item (1 v) of [list v] :: list) = [Apple]>Output is true.<case sensitive<(item (1 v) of [list v] :: list) = [apple]> ::operators>Output is false.<not <case sensitive <(item (1 v) of [list v] :: list) = [apple]> ::operators>>Output is true.<case [sensitive v] <(item (1) of [list v]) = [Apple]> :: operators booleans>
<case [insensitive v] <(item (1) of [list v]) = [Apple]> :: operators booleans>
That way we aren't messing with logic blocks.
That said, I'm sort of clueless on how one would actually implement this – obviously Scratch has never had any blocks like it. It would be, “first set a flag that the contained blocks should be executed case-sensitively (or not), then execute the contained blocks”; but as far as I can tell, Scratch block inputs are always executed before they're passed to the containing block. So I don't know if this would be possible with Scratch's code. But I think it would be pretty neat!
Oh yeah, one minor issue with it – suppose you want to stick “item #” into it? Then you'd get this (for example)..say <case [sensitive v] (item # of [Apple] in [list v] :: list) :: operators booleans>
We'd probably need two blocks – one for round-shape reporters, the other for boolean reporters. And that feels a little like a kludge to me, since they'd have exactly the same behavior, just different shapes.
Case sensitive {
Predicate <[] case sensitive ‹ [] :: operators>
Predicate <[] case sensitive = [] :: operators>
Predicate <[] case sensitive › [] :: operators>
Predicate <case sensitive Does text [] contain [] :: operators>
Reporter (case sensitive item # of [] in [list v] :: list)
Predicate <case sensitive [ v] contains [thing] ? :: list>
}
Case insensitive {
Predicate <[] < []>
Predicate <[] = []>
Predicate <[] > []>
Predicate <Does text [] contain [] :: operators>
Predicate <[ v] contains [thing] ?>
Reporter (item # of [] in [list v] :: list)
Last edited by Monniasza_spzoo (Aug. 19, 2019 11:12:30)
- Testingscratcher
- Scratcher
72 posts
Case Sensitivity Options
I don't know why but I feel like I'm confusing myself here… X3
Anyway, I look through this thread, and I also support, but with this in mind:
I'm thinking Scratch should be case-sensitive by default with this block implemented, too.
Anyway, I look through this thread, and I also support, but with this in mind:
((string) to case [options v]::operators)(with “options” being, primordially, UPPER, lower, or Title Case, among others)
I'm thinking Scratch should be case-sensitive by default with this block implemented, too.
Last edited by Testingscratcher (Aug. 19, 2019 13:49:39)
When Windows crashes::hat events
if <<(desperate) > [50]> and <(Windows) < [0]>> then
go to [Testingsoftware 2.0 v]
say [This is the all-new, next generation Scratch OS]
end
stop [using Windows v]
- EIephant_Lover
- Scratcher
500+ posts
Case Sensitivity Options
I don't think there's a need for a dropdown, as <not<case sensitive <>> would do just fine. -snip-
I don't see any need for this many blocks. -snip-
I think this would be especially confusing, as I haven't heard case sensitivity for being other than the exact same casing, or casing doesn't matter. How would your block even work? If it was set to title, would Apple = ApPLE? Because they both have the first one done? Or, if it has to be the same title case, then there's no need for options as a “case sensitive <>” would work, as all it varies is whether or not the casing is I don't know why but I feel like I'm confusing myself here… X3exactly the same or not.
Anyway, I look through this thread, and I also support, but with this in mind:((string) to case [options v]::operators)(with “options” being, primordially, UPPER, lower, or Title Case, among others)
I'm thinking Scratch should be case-sensitive by default with this block implemented, too.
Last edited by EIephant_Lover (Aug. 19, 2019 15:40:25)
- EIephant_Lover
- Scratcher
500+ posts
Case Sensitivity Options
I feel really dumb.
I just realized I've made another thread like this.
Although the other is technically the dupe, I'm going to link it and close this as it makes more sense than this one.
https://scratch.mit.edu/discuss/topic/357768/
Thanks
I just realized I've made another thread like this.
Although the other is technically the dupe, I'm going to link it and close this as it makes more sense than this one.
https://scratch.mit.edu/discuss/topic/357768/
Thanks
- Discussion Forums
- » Suggestions
- » Case Sensitivity Options