Open towerofnix opened 1 year ago
Just to make a case against such a function as this.daysSince(new Date(2000, 0, 1))
: IMO if we add a generic function, we're 1) opening up to arbitrarily going further than Scratch [with the standard library], which isn't a design goal of Leopard, and 2) limiting incentive to learn how that function works yourself, as a user, and come up with an alternative which suits your case more specifically.
We don't expose Leopard's inner workings to users right now, but overall, I think if we want to more specifically introduce users to JavaScript programming concepts, there are a number of better ways than by replacing a very compact standard utility with a bunch of "magic words" users will likely just copy and paste, gloss over, or be flat-out overwhelmed by.
If we want to simulate re-running a project deterministically [not generally but for the purpose of testing and catching behavior changes], we need to be able to mock this block anyway, which we basically can't do when directly accessing Date
behavior.
Right now sb-edit converts
sensing_dayssince2000
into this:In principle, this seems sound: "days since 2000" is a slightly ridiculous block and exposing users to real-world JavaScript date manipulation is basically a good idea.
The issue is, Scratchers aren't trying to figure out Date Mathematics when they use this block — and Scratch has blocks for date math. ("current minute", "current second", etc.) By replacing a simple Scratch block with much more complexity in JavaScript, we're only introducing overhead.
There exist a number of other functions (most recently
compare
& friends, as well asscratchTan
) which ensure compatibility with Scratch without bringing obtuse or overly-explicit syntax to generated projects. I think the behavior for "days since 2000" should be moved into one of these. Let's call it...this.daysSince2000()
! 👻