PullJosh wrote:

Recently I've been working on making a text rendering engine in Scratch, and have run into a bit of an issue: It's impossible to detect whether a letter is capital or lowercase in any sort of simple way. (Check it out!) The current methods involve forcing particular costume names, or adding an obscene number of variables (plus some hacked blocks) to the project.

I'd rather avoid forcing users of my custom block to give their sprite's costumes weird names, and I don't want to use hacked blocks if I can help it (in accordance with the ST's own sugguestions!)

This has led me back to thinking about the wonderful new “contains” block in 3.0. Should the “contains” block be case-sensitive?

Currently it isn't, and there are a lot of great cases to be made for keeping it that way. Making the block case-insensitive keeps it consistent with the = block and helps new Scratchers avoid difficult-to-understand bugs (particularly, I would imagine, when using the “contains” block in conjunction with the “answer” block). However, I would really like to see this changed. Giving users a variety of options, rather than sticking to consistency between the = and “contains” blocks, would allow for more programs to be made more easily.

For instance, here is a case detection script written with a case-sensitive “contains” block:

if <[ABCDEFGHIJKLMNOPQRSTUVWXYZ] contains (letter) ::operators> then
	set [uppercase? v] to [true]
else
	set [uppercase? v] to [false]
end

It's dead simple!

I understand that there are a lot of downsides to making the “contains” block case-sensitive, but there are also some considerable benefits. I'd be curious to know whether the Scratch team has already had a discussion about this, and what they think. (As well as the opinions of all of you fine folks here on the forums! )

walkcycle wrote:

some other threads

• Scratch 3 should be case sensitive
  
  
• Case Sensitive Equals Block
  
  
• Case sensitive C block ← my own
  

(should this be moved here?)

<((letter) to lowercase ::operators) = (letter) > // Report "true" if lowercase
<((letter) to uppercase ::operators) = (letter) > // Report "true" if uppercase

walkcycle wrote:

another option for the boolean

<[] is capital? ::sensing>

<(letter () of [world]) is capital? ::sensing>

PullJosh wrote:

It actually makes a lot of sense to add blocks to convert to uppercase or convert to lowercase, and leave the “contains” block alone. Case detection would still be easy:

<((letter) to lowercase ::operators) = (letter) > // Report "true" if lowercase
<((letter) to uppercase ::operators) = (letter) > // Report "true" if uppercase

Jonathan50 wrote:

Those would always report true because = isn't case sensitive.

Sheep_maker wrote:

walkcycle wrote:

another option for the boolean

<[] is capital? ::sensing>

I like this block, but the naming is ambiguous:

<[happiness] is capital? ::sensing>
<[UPPERlower] is capital? ::sensing>
<[123] is capital? ::sensing>
<[._.] is capital? ::sensing>

"C">"c" // false
"C"<"c" // true

<[C]>[c]> // false
<[C]<[c]> // false

Sheep_maker wrote:

Maybe the less than and greater than blocks can be made case-sensitive.
In JavaScript:

"C">"c" // false
"C"<"c" // true

In Scratch 2.0, both report false (because they're the same):

<[C]>[c]> // false
<[C]<[c]> // false

Since the only time the less than/greater than block is used with strings is with sorting, I don't think making the block case sensitive will break much projects.

EDIT:
“C”<"[" in JS returns true, but the same thing in Scratch returns false, so I'm assuming the less than/greater than blocks lowercases its inputs before testing

Sheep_maker wrote:

Maybe the less than and greater than blocks can be made case-sensitive.
In JavaScript:

"C">"c" // false
"C"<"c" // true

In Scratch 2.0, both report false (because they're the same):

<[C]>[c]> // false
<[C]<[c]> // false

Since the only time the less than/greater than block is used with strings is with sorting, I don't think making the block case sensitive will break much projects.

EDIT:
“C”<"[" in JS returns true, but the same thing in Scratch returns false, so I'm assuming the less than/greater than blocks lowercases its inputs before testing

<[Hello]< [world]> //input one would have a score of 1 and two would have 0
<[HeLlO]< [wOrLd]> //one=3 and two=2
<[ABCDEFGHIJKLMNOPQRSTUVWXYZ] < [abcdefghijklmnopqrstuvwxyz] > //one=26 and two=0 

TheUltimatum wrote:

Sheep_maker wrote:

Maybe the less than and greater than blocks can be made case-sensitive.
In JavaScript:

"C">"c" // false
"C"<"c" // true

In Scratch 2.0, both report false (because they're the same):

<[C]>[c]> // false
<[C]<[c]> // false

Since the only time the less than/greater than block is used with strings is with sorting, I don't think making the block case sensitive will break much projects.

EDIT:
“C”<"[" in JS returns true, but the same thing in Scratch returns false, so I'm assuming the less than/greater than blocks lowercases its inputs before testing

Wait you can use the “<” and “>” for comparing strings?

NitroCipher wrote:

Sheep_maker wrote:

Maybe the less than and greater than blocks can be made case-sensitive.
In JavaScript:

"C">"c" // false
"C"<"c" // true

In Scratch 2.0, both report false (because they're the same):

<[C]>[c]> // false
<[C]<[c]> // false

Since the only time the less than/greater than block is used with strings is with sorting, I don't think making the block case sensitive will break much projects.

EDIT:
“C”<"[" in JS returns true, but the same thing in Scratch returns false, so I'm assuming the less than/greater than blocks lowercases its inputs before testing

I think the best way to handle case sensitivity (using < & > ) would be to get the total score for capitalization.

<[Hello]< [world]> //input one would have a score of 1 and two would have 0
<[HeLlO]< [wOrLd]> //one=3 and two=2
<[ABCDEFGHIJKLMNOPQRSTUVWXYZ] < [abcdefghijklmnopqrstuvwxyz] > //one=26 and two=0 

• it might cause compatibility issues for older projects.
  
• it might not always be clear whether numbers should be treated as numerical values or ASCII values. Might cause issues with negatives, e-notation, etc.
  
• < and > might not be the way new scratchers would expect to test capitalization
  
• likewise, it's not obvious that those examples are testing capitalization. Inexperienced users might be confused when seeing this used in other people's projects (but that leads to a whole different discussion about the usability of string inequality at all)
  

Jonathan50 wrote:

Lol this is so cool! (Don't worry there's vertical blocks too)

NitroCipher wrote:

Jonathan50 wrote:

Lol this is so cool! (Don't worry there's vertical blocks too)

I believe the scratchblocks tag was a mistake. I removed it, and now the post makes a lot more sense. (though the images do appear spammy.)

MinecraftM153 wrote:

NitroCipher wrote:

Jonathan50 wrote:

http://i.cubeupload.com/sFT361.png
Lol this is so cool! (Don't worry there's vertical blocks too)
http://i.cubeupload.com/mttik5.png

I believe the scratchblocks tag was a mistake. I removed it, and now the post makes a lot more sense. (though the images do appear spammy.)

that version of scratch 3…. sooo bad
where can you get that!?

Jonathan50 wrote:

MinecraftM153 wrote:

NitroCipher wrote:

Jonathan50 wrote:

http://i.cubeupload.com/sFT361.png
Lol this is so cool! (Don't worry there's vertical blocks too)
http://i.cubeupload.com/mttik5.png

I believe the scratchblocks tag was a mistake. I removed it, and now the post makes a lot more sense. (though the images do appear spammy.)

that version of scratch 3…. sooo bad
where can you get that!?

That's what the scratch-blocks playgrounds looked like when they were first on GitHub in May 2016, it looks a lot better now The playgrounds are here now: http://llk.github.io/scratch-blocks/

That first image is what happens when you click “Sprinkles!” in the horizontal playground btw.

Ceo_ wrote:

They added a new block



I like it