Re: Re: Make things like Reflect an import instead of a global?
FYI, there is a discussion on built-in modules here: https://github.com/tc39/ecma262/issues/395 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Paren-free heads strawman
Isn't this very unnatural? If you are into this kind of thing, why don't you code Coffee for example? (Or don't since saving a few keystrokes isn't worth your dignity.) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Additional methods for Objects (like Arrays)
> Are these necessary given the introduction of Object.values() and Object.entries()? `Object.entries()` works. `Object.p.map()` would be shorter to write, easier to read and more compatible with functions already written for `Array.p.map()`. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Javascript Language feature Idea
More cool stuff:
```javascript
const arr = [1, 2, 3];
// Easy push
arr[] = 4; // => arr[arr.length];
// Easy s(p)lice
arr[begin, end];,
arr[begin,]; // => arr[begin, arr.length];
arr[begin, end] = [1, 2, 3];
```
A terrible example (terrible because this should be done with WebGL
shaders):
```javascript
const image = [ /* Umbagajillion of RGBA pixels */ ];
function manipulate(rgba) {
rgba[0] += 10;
rgba[1] += 10;
rgba[2] += 10;
}
for (let i = 0; i < image.length / 4; i++) {
const begin = i * 4;
const end = begin + 4;
/*
In case easy s(p)lice doesn't actually Array.p.slice
and just creates a limited view of the array
without breaking reference
(image[begin, end] === image[begin, end])
*/
manipulate(image[begin, end]);
/*
In case easy s(p)lice does Array.p.slice
and creates a new array
(image[begin, end] !== image[begin, end])
*/
const pixel = image[begin, end];
manipulate(pixel);
image[begin, end] = pixel;
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Javascript Language feature Idea
The "easy push" syntax exists in PHP so it will be familiar to at least some people. The slicey thing was also being discussed for PHP. I don't know if it landed or got dropped. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Propose simpler string constant
How are enums declared?
```javascript
let myVar = 13;
enum myEnum = {Red, Green, Blue};
// How does it work with classes?
class MyClass {
static myVar = 13; // "Class Fields & Static Properties" which omits "let"
static enum myEnum = {Red, Green, Blue}; // Now we decided to use "enum"
while we omitted "let" before
// Maybe "Class Fields & Static Properties" should use "let" and "const"?
}
```
Or:
```javascript
let myVar = 13;
let myEnum = enum {Red, Green, Blue};
// How does it work with classes?
class MyClass {
static myVar = 13; // "Class Fields & Static Properties" which omits "let"
static myEnum = enum {Red, Green, Blue}; // All fine?
}
```
---
Do we allow this:
```javascript
let myEnum = enum {Red, Green, Blue};
myEnum.Red; // 0 or Symbol("Red")
myEnum[myEnum.Red]; // Can we get "Red" like this?
```
If we do, how does this work?
```javascript
let myEnum = enum {Red, Green, Blue};
myEnum.Alpha = 3;
myEnum[myEnum.Alpha]; // Who is going to put "Alpha" here? It magically
happens? Probably not.
```
---
Take `HTMLMediaElement` for an example, which has these:
- HTMLMediaElement.HAVE_NOTHING = 0
- HTMLMediaElement.HAVE_METADATA = 1
- HTMLMediaElement.HAVE_CURRENT_DATA = 2
- HTMLMediaElement.HAVE_FUTURE_DATA = 3
- HTMLMediaElement.HAVE_ENOUGH_DATA = 4
And they can be used like this:
```javascript
if (myVideo.readyState >= HTMLMediaElement.HAVE_METADATA) {
goodToGo();
} else {
waitForIt();
}
```
How are we going to achieve the same functionality with "Symbol Enums"?
Don't use Symbols?
Make Symbols comparable or use something special like NumberSymbol which is
comparable like this?
Don't allow users to do this and have them implement methods like
`isReadyStateGreaterThan()` or `readyStateToNumber()`?
???
AFAIK, enums can do this in other languages:
```javascript
let myEnum = enum {Red = 2, Green, Blue};
// Green is 3, Blue is 4.
```
Maybe we can give the user to pick one:
```javascript
let myEnum = enum {Red, Green, Blue}; // Symbol Enum
let myEnum = enum {Red = 0, Green, Blue}; // Number Enum
```
Looks confusing.
---
How will a user be able to achieve an `HTMLMediaElement` like result?
(Making enum'd values properites of the class)
```javascript
class HTMLMediaElement extends HTMLElement {
// Like this?
static enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/}
// A "Number Enum" generates an object so use it with something crazy
like "Class Spread Properties"?
static ...enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/} // What?
// Maybe not supporting anything like above, and forcing users to put
enums in a property
static readyStates = enum {HAVE_NOTHING, HAVE_METADATA/*, ...*/};
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: The "Pipeline" Operator - Making multiple function calls look great
So these are your example utility functions:
```javascript
function capitalize (str) { /* ... */ }
function trim (str) { /* ... */ }
function splitBySpaces (str) { /* ... */ }
```
What makes you think that utility functions should be coded like that? Take
these for an example:
```javascript
// Using "this"
function trim(characters) {
// this...
return capitalizedString;
}
// Using a parameter
function trim(string, characters) {
// string...
return capitalizedString;
}
```
What is the best practice when coding functions like this? Using `this` is
a clear winner since that's how the native and user utility methods for the
`.prototype`s of String, Array and such work. More importantly, that's how
polyfills are done. Plus FBS, which allows very easy consumption of
functions coded like this, is already at stage 0.
When the functions in the PO examples should be coded with `this` anyway,
then where is the need for PO?
---
Also, you shouldn't make your examples this simple. It's almost like you
are deliberately trying to hide the truth.
This is the reality of current PO syntax:
```javascript
console.log(getSomething() |> _ => trim(_, '-') |> _ => words(_, /[^, ]+/g)
|> _ => pad(_, 20, '-'));
```
Even if there is a need for PO, the syntax should change:
```javascript
param1 |> func(param2, param3)
console.log(getSomething() |> trim('-') |> words(/[^, ]+/g) |> pad(20,
'-'));
```
Then it becomes something very close to FBS and doesn't look weird when
it's used with it everything else:
```javascript
'something'
::trim('-')
.concat('asd')
|>repeat(3);
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: The "Pipeline" Operator - Making multiple function calls look great
> I think you may be misunderstanding how the PO works. Specifically your example here: Just a typo. Let me list my concerns: - Supporting await makes things unnecessarily complicated. - Calling functions with more than one parameter is weird. - Looks like use cases are already covered by FBS. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Re: The "Pipeline" Operator - Making multiple function calls look great
This is a terrible example. It looks a lot better with what's already
available:
```javascript
async function runTask () {
const file = await fs.readFile('./index.txt');
const all = await* file
.split('\n')
.map(fs.readFile);
console.log(all.join('\n'));
}
```
Also how do you explain this feature to a newbie? This operator is supposed
to call the function at the RHS with the value at the LHS and now it also
has a special case when there is `await` at the RHS. How more complicated
will this proposal get for the sake of making it look useful?
This proposal's aim should basically be turning this:
```javascript
myFunc(myVar);
```
into this:
```javascript
myVar |> myFunc;
```
If it is not useful by just doing that then it should simply be rejected.
---
About the usefulness of this proposal, this one conflicts with the function
bind syntax and assuming FBS is all rainbows and unicorns and everyone
should use it, then this proposal makes no sense since the original example
should be written like this (and it's already good enough):
```javascript
function doubleSay () {
return this + ', ' + this;
}
function capitalize () {
return this[0].toUpperCase() + this.substring(1);
}
function exclaim () {
return this + '!';
}
const result = 'hello'
::doubleSay()
::capitalize()
::exclaim(); // "Hello, hello!"
```
It's also weird that how the RHS of PO become weird when the function takes
extra parameters. You can see how the code becomes polluted:
```javascript
// Have fbFunc) with 0 parameters
citizen::fbsFunc();
// Add a parameter to fbsFunc()
citizen::fbsFunc(param);
// Have opFunc() with 0 parameters
citizen |> opFunc;
// Add a parameter to opFunc()
citizen |> _ => opFunc(_, param);
```
So we would be lying if we said the PO syntax is `param |> func`.
The reality is:
```javascript
// FBS syntax:
param1::fbsFunc(param2);
// PO syntax:
param1 |> _ => opFunc(_, param2);
```
This is no good.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re: Just try
The recommended way of checking for file existence in Node.js is calling
`fs.stat()` on the file. If no error was passed to the callback, it exists.
If "ENOENT" was passed, it doesn't.
If you "promisify" `fs.stat()` and use it with async/await, it throws when
a file doesn't exist so you end up writing a lot of try/catches. You say
"Hey, it would be great if I didn't have to keep writing `catch(e){}`." but
what if the error wasn't "ENOENT"?
That's why I withdrew myself from suggesting such a thing. Carelessly
silencing errors is no good.
I like the idea of `let stuff = try something()` putting the error in
`stuff` but the problem is you can throw strings in JavaScript:
```
function getUserName() {
throw 'Error';
}
const userName = try getUserName();
if (userName instanceof Error) {
handleError(userName);
return;
}
console.log('There was no error, yay!');
// Actually there was
```
---
Also `try stuff() || undefined` will not be evaluated to `undefined` on
error:
```
> var err = new Error('Stuff blew up!');
undefined
> err || undefined
[Error: Stuff blew up!]
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
