Re: Pseudo headless arrows

[Michael Theriot]

Three equals used outside of strict equality might take some getting used
to `var fn ===> x`

On Thu, Apr 21, 2016 at 1:48 PM, Peter van der Zee  wrote:

> 
>
> There are two ways of writing argument-less arrows;
>
> () => x;
> _ => x;
>
> (Where `_` can be any identifier, of course.) I understand why we
> can't drop the head entirely so if we're forced to type anything at
> all, anyways, why not at least make it simpler by pressing two
> different keys instead of three/four:
>
> ==> x;
>
> I don't believe this leads to syntactical problems anywhere, not even
> with arrow functions themselves and it's future proof for at least the
> cases I'm aware of.
>
> It's a minor addition but I think it's much nicer than either of the
> two alternatives we currently have, which lead to a lot of
> inconsistencies (it's spaces and tabs all over again).
>
> Semantics are the same otherwise as `() => x` would be.
>
> - peter
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pseudo headless arrows

[Fabrício Matté]

@John: Good point.
IIRC, Mocha was (is?) one of such test frameworks that inspect the
function's `length` property in order to determine whether the author
intends the test to be run asynchronously (i.e. the first argument receives
a function that must be called when the test is done).
Whether that is a good practice is questionable, however.

/fm

On Thu, Apr 21, 2016 at 7:44 PM, John Lenz  wrote:

> _=>{} is a function that takes one param and is not equivalent to ()=>{}.
> Some test frameworks inspect the function and care about the difference.
> On Apr 21, 2016 3:34 PM, "Fabrício Matté"  wrote:
>
> The `==>` token would look like a new operator, which developers would
> have to look up in order to know exactly what it does. It is more confusing
> than helpful, IMHO.
> Also `==>x` has the same length as `_=>x`, the latter not introducing any
> new syntax (although it does employ an ugly unused identifier).
>
> By the way, this may be of interest to you: Headless Arrow Functions
> proposal .
>
> /fm
>
> On Thu, Apr 21, 2016 at 3:48 PM, Peter van der Zee  wrote:
>
>> 
>>
>> There are two ways of writing argument-less arrows;
>>
>> () => x;
>> _ => x;
>>
>> (Where `_` can be any identifier, of course.) I understand why we
>> can't drop the head entirely so if we're forced to type anything at
>> all, anyways, why not at least make it simpler by pressing two
>> different keys instead of three/four:
>>
>> ==> x;
>>
>> I don't believe this leads to syntactical problems anywhere, not even
>> with arrow functions themselves and it's future proof for at least the
>> cases I'm aware of.
>>
>> It's a minor addition but I think it's much nicer than either of the
>> two alternatives we currently have, which lead to a lot of
>> inconsistencies (it's spaces and tabs all over again).
>>
>> Semantics are the same otherwise as `() => x` would be.
>>
>> - peter
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pseudo headless arrows

[John Lenz]

_=>{} is a function that takes one param and is not equivalent to ()=>{}.
Some test frameworks inspect the function and care about the difference.
On Apr 21, 2016 3:34 PM, "Fabrício Matté"  wrote:

The `==>` token would look like a new operator, which developers would have
to look up in order to know exactly what it does. It is more confusing than
helpful, IMHO.
Also `==>x` has the same length as `_=>x`, the latter not introducing any
new syntax (although it does employ an ugly unused identifier).

By the way, this may be of interest to you: Headless Arrow Functions
proposal .

/fm

On Thu, Apr 21, 2016 at 3:48 PM, Peter van der Zee  wrote:

> 
>
> There are two ways of writing argument-less arrows;
>
> () => x;
> _ => x;
>
> (Where `_` can be any identifier, of course.) I understand why we
> can't drop the head entirely so if we're forced to type anything at
> all, anyways, why not at least make it simpler by pressing two
> different keys instead of three/four:
>
> ==> x;
>
> I don't believe this leads to syntactical problems anywhere, not even
> with arrow functions themselves and it's future proof for at least the
> cases I'm aware of.
>
> It's a minor addition but I think it's much nicer than either of the
> two alternatives we currently have, which lead to a lot of
> inconsistencies (it's spaces and tabs all over again).
>
> Semantics are the same otherwise as `() => x` would be.
>
> - peter
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Pseudo headless arrows

[Fabrício Matté]

The `==>` token would look like a new operator, which developers would have
to look up in order to know exactly what it does. It is more confusing than
helpful, IMHO.
Also `==>x` has the same length as `_=>x`, the latter not introducing any
new syntax (although it does employ an ugly unused identifier).

By the way, this may be of interest to you: Headless Arrow Functions
proposal .

/fm

On Thu, Apr 21, 2016 at 3:48 PM, Peter van der Zee  wrote:

> 
>
> There are two ways of writing argument-less arrows;
>
> () => x;
> _ => x;
>
> (Where `_` can be any identifier, of course.) I understand why we
> can't drop the head entirely so if we're forced to type anything at
> all, anyways, why not at least make it simpler by pressing two
> different keys instead of three/four:
>
> ==> x;
>
> I don't believe this leads to syntactical problems anywhere, not even
> with arrow functions themselves and it's future proof for at least the
> cases I'm aware of.
>
> It's a minor addition but I think it's much nicer than either of the
> two alternatives we currently have, which lead to a lot of
> inconsistencies (it's spaces and tabs all over again).
>
> Semantics are the same otherwise as `() => x` would be.
>
> - peter
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Pseudo headless arrows

[Peter van der Zee]

There are two ways of writing argument-less arrows;

() => x;
_ => x;

(Where `_` can be any identifier, of course.) I understand why we
can't drop the head entirely so if we're forced to type anything at
all, anyways, why not at least make it simpler by pressing two
different keys instead of three/four:

==> x;

I don't believe this leads to syntactical problems anywhere, not even
with arrow functions themselves and it's future proof for at least the
cases I'm aware of.

It's a minor addition but I think it's much nicer than either of the
two alternatives we currently have, which lead to a lot of
inconsistencies (it's spaces and tabs all over again).

Semantics are the same otherwise as `() => x` would be.

- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import wildcards on the right side of the statement

[Caridy Patiño]

Hey Francisco

There is nothing in the spec that prevent you from doing `import * from 
'shared/features/**/reducers';`, the module identifier is just a literal. What 
to do with it is not described by 262.

As for "from many", you can easily do that with a loader without having to 
introduce new grammar. The steps are simple, your loader will detect that 
module identifier (via hooks), as a result, it produces a new reflective module 
that is a composition of all the modules associated to the token in question.

/caridy

> On Apr 21, 2016, at 5:36 AM, Francisco Méndez Vilas  wrote:
> 
> import * from 'shared/features/**/reducers';

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import wildcards on the right side of the statement

[Matthew Robb]

This could be made to work as a feature in the server side. Basically you
are asking the server to give you a virtual rollup module where the body is
basically just a bunch of export * from 'x';. Where even that gets sticky
though is when dealing with default exports.
On Apr 21, 2016 7:11 AM, "kdex"  wrote:

> A browser couldn't possibly resolve globs at runtime without you providing
> some additional information to the runtime environment, so I don't see how
> this could be implemented.
> It's not really about browsers, anyway; the ES environment knows nothing
> about files, either. (meaning that `require` is something on top of v8 and
> doesn't belong to the language at all.)
>
> Even if you were to resolve these globs *somehow*; this could have huge
> impacts on performance, since the result of a glob is dynamic. Also, wasn't
> the `import` syntax supposed to
> be statically analyzable anyway?
>
> One could, however, try to make this work with a babel transform that
> transforms globs into multiple `import` statements.
> Then again, I neither think that a syntax shouldn't depend on its
> underlying file system nor that this would solve a case where you'd have:
>
> ```js
> import * as SingleBinding from "./some/glob/**/*.js";
> ```
>
> A cleaner pattern would be to import one single module that, itself,
> imports only the modules that it needs.
>
> On Donnerstag, 21. April 2016 09:36:51 CEST Francisco Méndez Vilas wrote:
> > Hi all,
> >
> > This is my very first proposal here, so please let me know if i'm not
> > following some rules.
> >
> > I want to make a proposal around the "import" syntax, it is, for
> instance:
> >
> > import * from 'shared/features/**/reducers';
> >
> > or
> >
> > import * from many 'shared/features/**/reducers';
> >
> > This came to my mind when developing an isomorphic Redux application
> where
> > i had to import all reducers of each feature. My tree structure looks
> more
> > or less like that:
> >
> > + shared
> >   + features
> >  + todos
> >+ actions
> >+ components
> >+ reducers
> >  - TodoReducer.js
> >  - index.js
> >  + users
> >+ actions
> >+ components
> >+ reducers
> >  - UserReducer.js
> >  - index.js
> >
> > If i have to import every "index.js" below each "reducers" directory, i
> > have two options, either manually import each of them or prepare a script
> > to walk through the tree and import them. Both of the approaches are
> really
> > weird.
> >
> > I really would like to have that feature in the language. What do you
> think?
> >
> > Cheers,
> > Francisco Méndez Vilas
> >
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import wildcards on the right side of the statement

[kdex]

A browser couldn't possibly resolve globs at runtime without you providing some 
additional information to the runtime environment, so I don't see how this 
could be implemented.
It's not really about browsers, anyway; the ES environment knows nothing about 
files, either. (meaning that `require` is something on top of v8 and doesn't 
belong to the language at all.)

Even if you were to resolve these globs *somehow*; this could have huge impacts 
on performance, since the result of a glob is dynamic. Also, wasn't the 
`import` syntax supposed to
be statically analyzable anyway?

One could, however, try to make this work with a babel transform that 
transforms globs into multiple `import` statements.
Then again, I neither think that a syntax shouldn't depend on its underlying 
file system nor that this would solve a case where you'd have:

```js
import * as SingleBinding from "./some/glob/**/*.js";
``` 

A cleaner pattern would be to import one single module that, itself, imports 
only the modules that it needs.

On Donnerstag, 21. April 2016 09:36:51 CEST Francisco Méndez Vilas wrote:
> Hi all,
> 
> This is my very first proposal here, so please let me know if i'm not
> following some rules.
> 
> I want to make a proposal around the "import" syntax, it is, for instance:
> 
> import * from 'shared/features/**/reducers';
> 
> or
> 
> import * from many 'shared/features/**/reducers';
> 
> This came to my mind when developing an isomorphic Redux application where
> i had to import all reducers of each feature. My tree structure looks more
> or less like that:
> 
> + shared
>   + features
>  + todos
>+ actions
>+ components
>+ reducers
>  - TodoReducer.js
>  - index.js
>  + users
>+ actions
>+ components
>+ reducers
>  - UserReducer.js
>  - index.js
> 
> If i have to import every "index.js" below each "reducers" directory, i
> have two options, either manually import each of them or prepare a script
> to walk through the tree and import them. Both of the approaches are really
> weird.
> 
> I really would like to have that feature in the language. What do you think?
> 
> Cheers,
> Francisco Méndez Vilas
> 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import wildcards on the right side of the statement

[ziyunfei]

Don't forget that JavaScript can run in the browsers.___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Import wildcards on the right side of the statement

[Francisco Méndez Vilas]

Hi all,

This is my very first proposal here, so please let me know if i'm not
following some rules.

I want to make a proposal around the "import" syntax, it is, for instance:

import * from 'shared/features/**/reducers';

or

import * from many 'shared/features/**/reducers';

This came to my mind when developing an isomorphic Redux application where
i had to import all reducers of each feature. My tree structure looks more
or less like that:

+ shared
  + features
 + todos
   + actions
   + components
   + reducers
 - TodoReducer.js
 - index.js
 + users
   + actions
   + components
   + reducers
 - UserReducer.js
 - index.js

If i have to import every "index.js" below each "reducers" directory, i
have two options, either manually import each of them or prepare a script
to walk through the tree and import them. Both of the approaches are really
weird.

I really would like to have that feature in the language. What do you think?

Cheers,
Francisco Méndez Vilas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss