my thoughts are the opposite. javascript (similar to perl and php) already
has a huge number of specialized builtin functions and methods accumulated
over its 20+ year evolution that pretty much solves every practical problem
encountered in frontend programming (and effectively backend as well). th
My thoughts: big source of JavaScript criticism is its small standard
library and community attempts to solve that issue - hundreds of small
modules. Significant part of lodash should be present in standard library.
My lodash selection - chunk, dropWhile, first, last, flatten, fromPairs,
pull, with
Dimitri I think what you're missing is that while yes the current proposal
and your proposal are not fundamentally different, the difference is that
overloading keywords is overloading into previously non existent design
space whereas overloading globals MUST consider the ramifications of
overloadi
> Nothing stops you from *explicitly* defining behaviour for `import.meta`.
Nothing stops you from *explicitly* defining behaviour of
Reflect/Proxy/Symbol/what-have-you.
> However, when the question comes to, say, replacing `import.meta` with
`X.y.z`, it becomes nigh impossible.
As has been menti
Honestly, I’ve seen the “you learn new thing and move on” so many times, I’m
getting tired of it.
I have ~10 years of experience with PHP and ~5 years of experience with
Coldfusion. Both experiences are pre-2010 (both languages somewhat improved
since then, even though I don’t know whether Cold
> The thing is, I clearly provide arguments in favour of my opinion.
>
> We now have:
> - keywords that are just keywords, really (typeof, case, break, etc.)
> ...
Totally fair. I understand that's where your coming from.
> How can adding “properties” to semantically fundamentally different
thing
> There’s no code anywhere which doesn’t have an object called Symbol
invoked with `new Symbol()`?
Any such code would either have a local `Symbol`, would have defined a
global `Symbol` that shadowed any pre-defined one (including the new global
in ES6), or would have thrown a ReferenceError or Typ
> [Reflect] Not a breaking change because adding a new global isn't new syntax,
> it's just a new variable that exists and essentially can't break much.
It either isn’t a breaking change, or can’t break much. It cannot be both.
> Not a breaking change because this constructor did not exist befor
FWIW, while I find needs like this common, too, where Map is sensible
instead of
Object, it does come out pretty clean:
```
const a = [
{id: "tjc", name: "T.J. Crowder"},
{id: "nc", name: "Naveen Chawla"},
{id: "lh", name: "Lachlan Hunt"}
];
const index = new Map(a.map(member => [ member.na
`await` could be added because there is no case in existing code where
`await ` would have been valid code, so it is
backward-compatible. The same applies for all of the meta-property
proposals. The same is not true for `Introspect.context.module`. It's not
just a question of it a given construct c
I just realised that there is also the argument that “global object cannot get
current context” and other limitations applied to whether a theoretical
“System/Module/Loader/Introspect” would be a global module, or object, or
keyword, or any (potentially context-sensitive) combination of these.
The problem with “metaproperties” is that they make the language more complex,
chaotic and make it difficult to reason about the language.
See my previous post about the multitude of keyword and keyword-like types that
the language has. It’s so bad that even “metaproperty” concept itself isn’t
Neither should emails have that. Please refer to [1] in the future.
Thank you!
[1] https://mail.mozilla.org/pipermail/es-discuss/2017-July/048584.html
On Saturday, August 5, 2017 6:35:19 PM CEST Dmitrii Dimandt wrote:
> Too bad emails don’t have "thumbs up" and “+1”s :) So here’s my "+1” to you
I really can't find a good resource on direct vs indirect evaluation but my
understanding is it's one of the main considerations for using a keyword
over an identifier for contextual information. One example which is already
in the language would be 'eval' which you can read a little about here:
ht
Too bad emails don’t have "thumbs up" and “+1”s :) So here’s my "+1” to you
On Sat, 05 Aug 2017 at 18:28 "T.J. Crowder"
<
mailto:
> wrote:
a, pre, code, a:link, body { word-wrap: break-word !important; }
On Sat, Aug 5, 2017 at 5:05 PM, Dmitrii Dimandt
<
mailto:dmit...@dmitriid.com
> wrote:
>
On Sat, Aug 5, 2017 at 5:05 PM, Dmitrii Dimandt
wrote:
> So, in my opinion, the argument for not adding new global entities
> such as System, or Module, or Loader (or heck, even all three of
> them) being “these are not keywords, we can’t introduce them” is
> really really weak.
Is anyone making
Introduced in ECMASCRIPT 2015: Reflect is a built-in object that provides
methods for interceptable JavaScript operations.
Introduced in ECMASCRIPT 2015: The Symbol() function returns a value of type
symbol, has static properties that expose several members of built-in objects,
has static meth
Yes super is a keyword and had been reserved for a long time. I don't
necessarily disagree with your premise about introducing new keywords that
aren't reserved but the current tc39 policy on this is to not due to the
high likelihood that it breaks current user code.
This conversation could go ver
That’s not what I was really aiming at :)
The original concern was “to get ‘module’ : 1. It's a context-sensitive
keyword, and code that's using it needs to
be updated when migrated to a module. “
I was just pointing out that ‘import’ is already a context-sensitive keyword
(as are a bunch of
Languages *evolve*. It means that at some point something will be introduced
that may break existing user code.
I understand that with JS the problem is compounded a billion-fold (JS is used
quite literally everywhere).
However: Looking at the evolution of JS we can see that new entities and ne
Ah but you can do:
export function meta(key) {
return import.meta[key]:
}
On Aug 5, 2017 11:59 AM, "Dmitrii Dimandt" wrote:
> Import is already made to be a context-sensitive keyword
>
> I don’t think you can have a
>
> function x() {
>import {x} from ‘module’;
> }
>
>
>
> On Sat, 05 Aug 20
Can anyone knowledgeable on the topic of direct vs indirect evaluation
chime in with an explanation or a link to one as my understanding is enough
to "get it" but not too really explain it.
On Aug 5, 2017 11:57 AM, "Dmitrii Dimandt" wrote:
> Exactly! import.meta doesn’t make import an object. ne
Import is already made to be a context-sensitive keyword
I don’t think you can have a
function x() {
import {x} from ‘module’;
}
On Sat, 05 Aug 2017 at 13:07 "T.J. Crowder"
<
mailto:
> wrote:
On Sat, Aug 5, 2017 at 11:58 AM, Naveen Chawla
<
mailto:naveen.c...@gmail.com
> wrote:
>
> How
Exactly! import.meta doesn’t make import an object. new.target doesn’t make new
an object. function.sent doesn’t make function an object.
These are just purely arbitrary things tacked on top of randomly selected
keywords because at one point someone needed some *introspection* info (such as
“cu
It all boils down to direct and indirect evaluation and static contextual
information. It can't be an identifier any more than super or this. It
can't be passed because it's a different type of evaluation that happens
relative to static context, in this case the containing module body.
You can pas
Yes although it could be implemented like an object & function underneath
even if it's not officially exposed as one.
I think the key question is for interested TC39 members - whether passing
it around must be expressly disallowed or allowed. If allowed, `module` is
the only choice that won't go a
On Sat, Aug 5, 2017 at 3:08 PM, kdex wrote:
> Could you please elaborate on that?
It's not important here. :-) I've replied off-list. (If anyone feels
strongly that the reply is relevant, let me know and I'll repost it to the
list, but...)
-- T.J. Crowder
Inline.
On Saturday, August 5, 2017 1:35:35 PM CEST T.J. Crowder wrote:
> On Sat, Aug 5, 2017 at 11:18 AM, Naveen Chawla
>
> wrote:
> > I've often needed to cache array elements by a unique key each
> > element has, for quick access.
>
> Yes, please. I've needed this in every codebase I've ever
On Sat, Aug 5, 2017 at 2:35 PM, Naveen Chawla wrote:
>
> Thanks for the link! That means that `import` is already on the
borderline of the spec since it wants to be a function and object.
No, not at all. It's a keyword. `import.meta` doesn't make `import` an
object, any more than `new.target` mak
Thanks for the link! That means that `import` is already on the borderline
of the spec since it wants to be a function and object. `module` would
eliminate all confusion and restriction but as you said, only if passing it
around must be expressly disallowed - need an interested TC39 member to
weigh
On Sat, Aug 5, 2017 at 1:46 PM, Naveen Chawla
wrote:
>
> I think it has to be an identifier, especially given proposals
> like `meta`, dynamic functionality etc.
There's a slight misunderstanding here about the term "identifier" that may
be preventing your fully understanding what I'm saying. `im
I think it has to be an identifier, especially given proposals like `meta`,
dynamic functionality etc. The question for me is whether it's `import` or
`module`. Suppose it's `import`: already proposed to act as a per-module
function (`import()`) with a property (`import.meta`) are we trying to
prev
On Sat, Aug 5, 2017 at 1:05 PM, Lachlan Hunt
wrote:
> But basically, is the proposal for a native version of Lodash's
> `_.keyBy()` method?
Well, that's how I read it, yes; along those lines anyway.
-- T.J. Crowder
___
es-discuss mailing list
es-discus
On 2017-08-05 21:47, T.J. Crowder wrote:
On Sat, Aug 5, 2017 at 12:41 PM, T.J. Crowder
wrote:
Apologies, better proofreading required, left out the `"id"` argument:
```js
const a = [{id: "tjc", name: "T.J. Crowder"}, {id: "nc", name: "Naveen
Chawla"}, {id: "lh", name: "Lachlan Hunt"}];
const i
On Sat, Aug 5, 2017 at 12:41 PM, T.J. Crowder
wrote:
Apologies, better proofreading required, left out the `"id"` argument:
```js
const a = [{id: "tjc", name: "T.J. Crowder"}, {id: "nc", name: "Naveen
Chawla"}, {id: "lh", name: "Lachlan Hunt"}];
const index = Object.from(a, "id");
console.log(in
On Sat, Aug 5, 2017 at 12:22 PM, Lachlan Hunt
wrote:
>
> On 2017-08-05 20:18, Naveen Chawla wrote:
>>
>> I've often needed to cache array elements by a unique key each
>> element has, for quick access.
>>
>
> That looks like what Array.prototype.map can already do.
No, the end result is an object
On Sat, Aug 5, 2017 at 11:18 AM, Naveen Chawla
wrote:
> I've often needed to cache array elements by a unique key each
> element has, for quick access.
Yes, please. I've needed this in every codebase I've ever worked on. For
me, having it in the standard lib would be a win. (Yes, you can easily d
On 2017-08-05 20:18, Naveen Chawla wrote:
I've often needed to cache array elements by a unique key each element has,
for quick access.
This is a shortcut:
```javascript
const elementsById = elements.toObjectByProperty(element=>element.id);
```
That looks like what Array.prototype.map can alr
I'd find it helpful to have:
1. A general steer from TC39 as to whether the committee are committed
to a robust, feature-rich standard library, or a minimal one (with the
expectation of a rich ecosystem of libraries, presumably).
2. Guidelines of what to consider when proposing standard library f
On Sat, Aug 5, 2017 at 11:58 AM, Naveen Chawla
wrote:
>
> How is `document` and `window` handled when someone does
> `const document =` ?
At global scope in a script body, in a browser context, it's an error,
as you presumably know, because `document` is already declared.
> It would seem perfect
How is `document` and `window` handled when someone does `const document =`
? It would seem perfectly fine to allow `module` to be masked by other
variables, and if someone wants to use the module-global `module`, they can
just rename in order to get access. It is analogous to `document` /
`window`
On Sat, Aug 5, 2017 at 11:45 AM, T.J. Crowder
wrote:
> ...But there's something *like* a precedent...
Also `set` and `get` in object initializers and classes. (Apologies for
double-posting.)
-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozill
On Sat, Aug 5, 2017 at 11:05 AM, Naveen Chawla
wrote:
>
> Does existing code use modules??? My understanding is that
> modules are a recent concept.
Yes, people have been using ES2015-style modules for a couple of years now
(obviously, modules in general much longer than that), via transpilers an
I've often needed to cache array elements by a unique key each element has,
for quick access.
This is a shortcut:
```javascript
const elementsById = elements.toObjectByProperty(element=>element.id);
```
Support?
___
es-discuss mailing list
es-discuss@m
Does existing code use modules??? My understanding is that modules are a
recent concept. And the `module` keyword would only apply in actual modules
Pls correct me if I'm wrong
On Sat, 5 Aug 2017 at 15:21 T.J. Crowder
wrote:
> On Sat, Aug 5, 2017 at 10:13 AM, Naveen Chawla
> wrote:
> >
> > I w
On Sat, Aug 5, 2017 at 10:13 AM, Naveen Chawla
wrote:
>
> I would be comfortable with `module.import()` and `module.meta`
> instead of `import()` and `import.meta`, simply because the name
> `module` more automatically describes the module specific "global"
> object than `import` does.
If `module
I would be comfortable with `module.import()` and `module.meta` instead of
`import()` and `import.meta`, simply because the name `module` more
automatically describes the module specific "global" object than `import`
does. Also, it more explicitly communicates that the "import" is specific
to the m
47 matches
Mail list logo
