21–30 of 85 posts
> There are a number of proposed changes to Classes, including field declarations, private methods and fields, and static methods and fields. So make it look full on like traditional OOP with classes, I guess? I suppose the prototype folks lost this debate.
If fields in class definitions are incorporated I would like it to simultaneously make the field names in scope for any methods within the class definition.
class Fish extends Vertebrate {
color = "blue";
constructor (speed) {
super();
this.speed = speed;
if (speed > 5) color = "red" // does not need this.color because color is a class field.
}
}
Fish.prototype.setColor = function (newValue) {
this.color = newValue; // this. is required because this function is outside the class definition.
}
I wonder whats the reasonig behind it? `private` is already a reserved word in JS, why not just use it? https://www.w3schools.com/js/js_reserved.asp
I'm alerted that javascript tends to bloat the stdlib. Most of the features mentioned can be implmented as a external library. This is benefitial for users as they can switch the implenmentation and upgrade versions without waiting for all of their users to upgrade the runtime first. The prime example of javascript unnecessary bloat is fetch api which is mere wrapper for ajax calls, was developed a while ago but stil…
I do believe your concerns are still real ones, however. Fortunately, we can poly-fill.
I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…
@downvoters: do you care to add a reply? it’s silly that instead of having a conversation, we’re doing this.
[].concat(...arrayOfArrays)
So, like, the simplest example is if you're just getting a bunch of results from a paginated source -- you want to flatten them, and it is really nice to just have a method for that.
The list monad case is more interesting because it gives a syntax for list comprehensions:
[ x + y for x in list1 for y in list2 if x % 2 == 0 and y % 2 == 1 ]
list1.flatMap(x =>
x % 2 !== 0 ? [] : list2.flatMap(y => (y % 2 == 0 ? [] : x + y))
);
I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…
As a beginner it's a far more daunting picture, compared to Rails for example, but as a practitioner I'd like to build my project with pieces suited for purpose.
I might get heat for this but personally I find the JavaScript ecosystem to be a mess. There are so many changes to the language that are done aggressively which I think are done without much thought. For example, the promises API, now we also have async/await. The module system, with require(s), then import/export, and there's browser JS and system JS (node), and npm and now yarn, then your build system, with webpac…
I don't have the actual transcript so summarizing based off of someone else's comments:
* I added promises to Node in June 2009 but foolishly removed them in February 2010. * Promises are the necessary abstraction for async/await. * It's possible unified usage of promises in Node would have sped the delivery of the eventual standardization and async/await. * Today Node's many async APIs are aging badly due to this.
#this_is_not_a_comment = 6;
Yeah... it's ugly as heck but they're clearly trying to avoid new keywords. I hope the TypeScript folks can convince ECMA to adopt normal keywords like they use: https://www.typescriptlang.org/docs/handbook/classes.html
For example, what does `this.foo` access in an object? the private property `foo`? the public property `foo`? What about if I'm using your object and put a new property `foo` on it after it's created, then what happens?
None of the answers to those questions are really good. If the private shadows the public, then how do you access the public? If it's the other way around, then external users can break your private fields by adding a public of the same name, which kind of defeats the purpose...
TypeScript can get away with it because it's not really enforced by the runtime, only the typechecker, so their `private` isn't really private outside of TypeScript.
[1] https://github.com/tc39/proposal-class-fields/blob/master/PR...