3 ms·
Nothing is more unreadable than "readable" names. I absolutely detest working with code that uses for example stuff like ImmutableJS, that turns every property
by BigJono 3y ago
Nothing is more unreadable than "readable" names. I absolutely detest working with code that uses for example stuff like ImmutableJS, that turns every property access into `.get('')` instead of a simple `.` operator.
I wouldn't use this for no reason or just to be fancy, but if you're working in a context that legitimately requires integer division all over the place, you should use syntax for it if it's available.
I'd be annoyed if I had to work with something maths-y that has gigantic lines full of Math.trunc() everywhere.
- moritzwarhier 3y agoI don't think having to use .get() for property access is equatable to "readable names". It is also not the reason for this in the library you mentioned AFAIK, although I haven't used it so far. I think the reason for the .get() is that it is not achievable to have deep immutability in JS with regular property access (Object.freeze is not "deep" either). That aside, I agree it's not ergonomic, but it has nothing to do with readable names. And converting a string to an integer is not possible with a native JS operator intended for this purpose, so I'd prefer Math.trunc any day. Regarding the immutable.js thing, the Records/Tuples TC39 proposal aims for a syntax and runtime addition to allow immutable objects with regular dot property access.