2 ms·
> Once you know that “Java says X is the first day of the week,” The basic assumption when designing anything is that you can never rely on assuming that other
by jcelerier 5y ago
> Once you know that “Java says X is the first day of the week,”
The basic assumption when designing anything is that you can never rely on assuming that other humans "will" know.
- xxs 5y agoA funny part is that java has java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar. It's considered a bad design overall, esp with SUNDAY const being 1. For most of the world that (sun=1) made absolutely no sense at all and assumed one of those weird things like jokes about IQ and room temperature.
- filoeleven 5y ago> java.util.Calendar that has setFirstDayOfWeek(int), the default depends on the locale used to create the Calendar That is exactly the kind of hidden assumption that I’m trying to fight against! If the date and the locale were both passed in as parameters, preferably just plain data, this would be a transparent function. Instead, you have to find and read through the documentation to see what kind of mischief is going on. And you have to do that every time you encounter a Java.until.Calendar. Edit to clarify: if “locale” is some class, you have to learn that class DSL to examine it, and depend on a runtime debugger that does the same. If “locale” is just a hash map, you can examine the values without a lot of faff.
- filoeleven 5y agoSure, but how far does that go? If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling? Some level of understanding is necessary. I want it to also be reasonably explicit. Java time library doesn’t meet that standard until Instant.
- jcelerier 5y ago> If I try to assign an int value to “3.2” will the language silently fail with null, or a round, or a floor, or a ceiling? one may argue that the only correct thing to do here is a compile-time error