So Snap*!* 9.0 released (I think it was actually 9.1 - I don't use Snap*!* daily) when I was working on my chess project, debugging en passant, and optimising check detection, when I went to run the project and it was not right. The pieces on the top of the board were white.
The project used costumes, named with capital letters for white pieces and lowercase Ietters for black pieces. I already knew from development builds of 9.0 that it added a case-sensitivity checkbox, so I put two and two together and knew that you made that preference determine costume case-sensitivity whilst forgetting that costumes were case-sensitive.
The old behaviour was inherited directly from Scratch - and it's a good thing. Unlike sprite case-sensitivity, which I have only ever seen used once by qucchia, costume case-sensitivity is likely intentional, as it has a use which is obvious - text rendering.
They added costume case-sensitivity so projects could be more intricate. By making the case-sensitivity of costumes based on the checkbox, that just broke many Snap*!*inator'd projects and most Scratchers expectations. In my case, this wasn't related to rendering text (it had to do with implementing FEN strings), and I know backwards compatibility is a touchy subject.
It's just that many Snap*!* users come from Scratch, and they expect that costumes are case-sensitive. It also didn't help that Snap*!* 9.0 had no means of drawing text with any font - only a monospace one is available.
(drag this picture into the snap editor to get blocks) These blocks will be officially added when snap 10 releases (tomorrow, according to @cymplecy), but you can still use them now.
That's different from using costumes, because costumes can be a custom font, not just built in fonts. Also, it's not super easy to move a bunch of the letters around after drawing them (it is possible, but not as easy as just using predefined costumes).
Oh dear. I definitely see the need to support case-sensitive costume names for that particular use case, but we do support them; that's why there's the setting. (This is the first such use case that really convinces me, by the way.)
But I still feel strongly that case-insensitive identifiers is the right choice, in general, in a language for learners. (Okay, I admit it, I think it's the right choice in professional languages, too. Relying on case sensitivity is just asking for bugs, especially if you have two identifiers theRealDeal and TheRealDeal.)
Generally when we make a backward-incompatible change we recognize projects saved before the change on loading and retrofit them automatically. Did we not do that this time?
I'm almost tempted to suggest that single-letter costume names should be case-sensitive, as a "do what I mean" special case, but no, I guess not.
I feel like costume names should look for the case sensitive name check first, then if the costume was not found, do a case insensitive check. It has the best of both worlds.
That would be true if the only point was to prevent no-such-object errors. But another point is to prevent bugs in which the one you get isn't the one you wanted.
I mean, your solution would be better than nothing. But I think there is no "best" to case sensitivity for identifiers. It's all bad.
Case insensitivity is one of these features that are amazingly ambiguous for all the wrong reasons. I've long been an opponent because I believed it to be a nostalgic remnant of the early LOGO architecture, a technical quirk that became glorified in retrospect. But once I delved into the domain of natural language modeling and (modern) AI I totally changed my mind and became convinced about its almost unbelievable pedagogical (and expressive!) benefits. Language representing what people speak doesn't need (or even know) typography or upper cases. Therefore when you're making projects that involve language, such as building a chat bot, a gesture recognizer, or some message-intensive concurrent state machine the capabilities you get from not having to worry about cases are liberating to the point of being amazing.
The downside is that when you're "solving" classical problems such as looking up keywords in a data base you are prone to get false positives if you don't take cases into consideration. Sadly, school books and CS curricula are full of dull and boring - and terribly outdated - problems requiring students to model, e.g. a data base for DVD rentals (I'm not kidding, look it up, it's true, anybody remember DVDs?), and not about exploring natural language (which has become all the rage in the real world nowadays). That's why we've added a setting so you can easily and even programmatically toggle between case sensitivity and natural language mode. If you have an old project that relies on case sensitivity you can simply turn that setting on and it'll continue to work as before.
I barely remember DVD rentals, but I own a small, cherished collection of classic films, including Casablanca, The Maltese Falcon, On the Waterfront, Dr. Strangelove, A Hard Day's Night, the Lord of the Rings trilogy (the long versions), Dark Star, West Side Story (the original of course), Malcolm X, l'Argent de Poche, Dead Poets Society, About a Boy, Explorers, The TAMI Show, Pirate Radio (mainly for the intro!), ... and an even smaller collection of TV shows: The Prisoner, Animaniacs!, Babylon 5, and Rocky and Bullwinkle.
But, you know, I've been known to type "dead poets society" into a search engine, and I don't consider it a false positive if it tells me what I want to know! Are there a lot of cases in which there are two movies with the same name except for case? I guess you could make a case that "Bell Hooks" should fail instead of giving you the Wikipedia article on bell hooks.
But if AI has gotten you onto the right side with respect to case sensitivity, that makes it all worthwhile! :~D
