Re: A plan to help TC39 become more open up to community contributions and participations
@John @Michał ES6 expanded the language greatly indeed, but the expansion is incomplete with lots of glaring holes. I happen to be researching into the crazily deficient Map/Set APIs recently as well, and found a few documents - only from 1.5 years ago but apparently are quickly falling out of people's memories - that hold the answer: https://esdiscuss.org/topic/map-filter-map-and-more https://esdiscuss.org/notes/2014-11-19 https://esdiscuss.org/notes/2014-11/Map.prototype-extensions.pdf We wanted a generic Iterator prototype but (again) we didn't have the time, so we just left a giant hole in there without a timeline on patching it, and everyone who'd like to use Map for collections now have no choice but to turn to some 3rd party solutions like Immutable.js - which totally replaced ES6 Map/Set implementations with its own. This is kinda ridiculous honestly. I think with enough community involvement being enabled, we can see some positive changes such as information on why some previous proposal has been turned down can become more transparent and organized; the need of some essential, hole-patching proposals can become more apparent with a clear direction, and potentially see some good ones from the community. Again **due to Ecma International's IPR policies**, we need a community member inside TC39 itself to enable this possibility. On Sat, May 28, 2016 at 10:41 AM, G. Kay Lee < balancetraveller+es-disc...@gmail.com> wrote: > First - thanks for everyone who chipped in; any comment is of immense > value here. > > @Kevin > > **The "us-vs-them" mentality**: IMHO the mentality kinda came into > existence precisely because of the aforementioned fact that the current > experience for community participation is not a smooth and - more > importantly - *transparent* one for those "not in the loop". > > Since you've mentioned the obvious I dared not to mention that es-discuss > has been largely marginalized, I believe you can also imagine that the most > likely way for average ECMAScript users out in the wild nowaday to gain > insight into the progress of TC39's works is by following certain > high-profile representatives' Twitter and GitHub activities. This is > rendering the community on the totally passive end of things. And this > doesn't work well when occasionally the community is trying to drive > something when people have come to realize they really want it. > > I've mentioned inside the original discussion thread that the proposer of > that pipe operator would have a far better luck gaining attention and > finding a champion if the proposer went on to pitch-off representatives on > Twitter one-by-one. Which is impossible, and would lead to the inevitable > that people would just start pestering certain most visible champions like > *ljharb*, *rwaldron*, and perhaps *zenparsing* :-p > > The thing is - if we disregard those "I have an idea..." or "I want this > thing from language X..." type of threads and only count those with a > dedicated GitHub repo as a *proposal* - the good-n-bad ratio is kinda > half-half. It's not as low as you depicted because many of these are > recurring proposals trying to address some long-standing language issues > since eons... But most of the "good" (ie. worthy of further works) ones > simply died a slow death they did not deserve without any reason being > revealed - taking on the example of that pipe operator again, it's dying > right now because of some reason that's *yet to exist*. They were told to > come to es-discuss to seek for champions and then the journey simply > stopped. Whether it's due to something bad about the proposal or some bad > timing, no one really knows. The community is just being left in the dark > to guess on things. > > Good proposals that did gain attention from representatives do exist, > like Claude's Optional Chaining you've mentioned (which surprised me > because I was thinking about working on the same thing and unaware of any > quality community effort already in progress), but it's undeniable that > Claude's long-time participation on the list has helped a lot in this > regard. While trust is also a factor, I'd hope that representatives can > have more faith in contributions from not-so-familiar names. There are > still good ones out there. > > All these clues are hinting toward one direction - that we need a place to > collaborate on community-driven efforts, a place we can list out all past > and current community proposals - who's working on what already, how things > need to be improved, why things were being turned down, and most > importantly: get transparent feedbacks on how these proposals fare inside > TC39. > > ***Due to [Ecma International's IPR policies]( > http://www.ecma-international.org/memento/Ecma%20IPR%20policies.htm)***, > such endeavor will be extremely difficult to be initiated from TC39's side, > and that's why I reached the conclusion that the only way to possibly > address this whole community involvement
Re: A plan to help TC39 become more open up to community contributions and participations
First - thanks for everyone who chipped in; any comment is of immense value here. @Kevin **The "us-vs-them" mentality**: IMHO the mentality kinda came into existence precisely because of the aforementioned fact that the current experience for community participation is not a smooth and - more importantly - *transparent* one for those "not in the loop". Since you've mentioned the obvious I dared not to mention that es-discuss has been largely marginalized, I believe you can also imagine that the most likely way for average ECMAScript users out in the wild nowaday to gain insight into the progress of TC39's works is by following certain high-profile representatives' Twitter and GitHub activities. This is rendering the community on the totally passive end of things. And this doesn't work well when occasionally the community is trying to drive something when people have come to realize they really want it. I've mentioned inside the original discussion thread that the proposer of that pipe operator would have a far better luck gaining attention and finding a champion if the proposer went on to pitch-off representatives on Twitter one-by-one. Which is impossible, and would lead to the inevitable that people would just start pestering certain most visible champions like *ljharb*, *rwaldron*, and perhaps *zenparsing* :-p The thing is - if we disregard those "I have an idea..." or "I want this thing from language X..." type of threads and only count those with a dedicated GitHub repo as a *proposal* - the good-n-bad ratio is kinda half-half. It's not as low as you depicted because many of these are recurring proposals trying to address some long-standing language issues since eons... But most of the "good" (ie. worthy of further works) ones simply died a slow death they did not deserve without any reason being revealed - taking on the example of that pipe operator again, it's dying right now because of some reason that's *yet to exist*. They were told to come to es-discuss to seek for champions and then the journey simply stopped. Whether it's due to something bad about the proposal or some bad timing, no one really knows. The community is just being left in the dark to guess on things. Good proposals that did gain attention from representatives do exist, like Claude's Optional Chaining you've mentioned (which surprised me because I was thinking about working on the same thing and unaware of any quality community effort already in progress), but it's undeniable that Claude's long-time participation on the list has helped a lot in this regard. While trust is also a factor, I'd hope that representatives can have more faith in contributions from not-so-familiar names. There are still good ones out there. All these clues are hinting toward one direction - that we need a place to collaborate on community-driven efforts, a place we can list out all past and current community proposals - who's working on what already, how things need to be improved, why things were being turned down, and most importantly: get transparent feedbacks on how these proposals fare inside TC39. ***Due to [Ecma International's IPR policies]( http://www.ecma-international.org/memento/Ecma%20IPR%20policies.htm)***, such endeavor will be extremely difficult to be initiated from TC39's side, and that's why I reached the conclusion that the only way to possibly address this whole community involvement issue is by installing a member organization that represents the community itself, thus *"hacking"* through the restrictive structure that Ecma International abides by. So the plan is trying its best under the rules of Ecma International to put an end to the already existing "us-vs-them" sensation - not the other way around. **Time is not enough**: Yes, just like, always, no? ;-) With a more organized community at your side, we can help tackle existing proposals, too. Some proposals have been stranded for quite some time (eg. [Relationships]( http://wiki.ecmascript.org/doku.php?id=strawman:relationships), [ArrayBuffer.transfer]( https://gist.github.com/lukewagner/2735af7eea411e18cf20)); it's not very obvious to the community at all that whether they need more works, more debates, or the background and situations have changed and that they're no longer that important, etc. A well-organized community can help with logistics and maintenances to make the information more readily available, so efforts can go where they need to go, and you (and people who'd like to wholeheartedly devote to drafting up proposals) can have more time to focus on things you're really interested in. On Fri, May 27, 2016 at 11:50 PM, Michał Wadas wrote: > To be honest - I can rather see complaining about how small is the > standard library, and how many basic functions have to be provided by third > party, not by standard library (famous left-pad case). > > And I think these complaints are right and justified - newly introduced > classes like Set are painfully limited
Re: A plan to help TC39 become more open up to community contributions and participations
To be honest - I can rather see complaining about how small is the standard library, and how many basic functions have to be provided by third party, not by standard library (famous left-pad case). And I think these complaints are right and justified - newly introduced classes like Set are painfully limited. We don't have a set.filter method, .map method, .intersect method, .union method, .difference method - everything have to be reimplemented by every developer. How long we had to wait for Object.entries? How long we will have to wait for someone to propose Object.fromEntries? Tuples, named tuples, counters, functional Date, deque, cryptography primitives, advanced marshalling, parallelism, structs, UUUIDs, weak references - all these basic functionalities are lacking in JavaScript... And these are not an "ultra high level" functions, but rather a basic building blocks. Yesterday I have think about idea of "official staging library" - a set of modules that are staging for inclusion in the official specification. Faster release cycles, better feedback, community-driven, better implementation, lesser worry about backward compatibility. If some feature is getting a positive feedback from community it becomes part of the next standard. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: "Object.hasOwnProperty"
Reflect is only for API mirrors to Proxy traps - that's why Reflect.enumerate was removed along with the Enumerate Proxy trap. On Friday, May 27, 2016, Isiah Meadows wrote: > I'd, for ergonomic reasons, would prefer it on Reflect. I very frequently > alias this function, so having it as a static method on Reflect would be > nice. > > On Thu, May 26, 2016, 17:42 doodad-js Admin > wrote: > >> >> This would break a Web, a I have seen code that relies on >> Object.hasOwnProperty === Object.prototype.hasOwnProperty >> >> Sorry, I didn’t remember that the constructor inherits it. >> >> >> Anyway, it would be handy to have such function as `Reflect.hasOwn` or >> something like that. >> >> Yeah, maybe that then. Or “System.ObjectHasOwn” or else. >> >> Thanks >> ___ >> 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: Error-Type Specific try/catch Blocks
I still can't see why it's superior to standardizing SpiderMonkey
non-standard syntax.
```
try { ...
} catch(e if e instanceof Error) {
}
```
I think it's rather inferior, because your doesn't allow C#-like exception
filters. It saves you 14 characters, but limits your "easy" filters to
`instanceof`.
To quote article on C# exception filters:
> For example, let’s say you are writing code to perform some operation
against a dependency, and that dependency will throw an exception with a
*bool* property that tells you whether the operation *IsRetryable*.
> Now, let’s say that as we’re calling this dependency, we want to be able
to retry any error that has *IsRetryable == true* up to three times, then
abandon if it throws a fourth time.
I think it's legitimate use case and why can't we kill two birds with one
stone? Moreover, I think it's bad idea to add static typing to language in
only one place (catch clauses).
On Fri, May 27, 2016 at 11:05 AM, Arthur Stolyar
wrote:
> Something wrong with prev link.
> https://github.com/zenparsing/es-typed-catch
> On May 27, 2016 12:00, "Arthur Stolyar" wrote:
>
>> If something, here seems to be another similar proposal:
>> https://github.com/zenparsing/es-typed-catch
>>
>
> ___
> 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: A plan to help TC39 become more open up to community contributions and participations
Maybe also a factor: JS has changed a huge amount in a short time. Developers, browsers, tools need to catch up, digest the changes, decide what real problems remain. We have enough new for now. On Fri, May 27, 2016 at 7:42 AM, Kevin Smith wrote: > Thanks for pointing out some issues with the current state of things. > While, in general, having more people directly participate in the committee > is probably a good thing, I don't think that will fix the problem. I think > you'll find yourself running into the same troubles that the current > members face. Specifically, there is more work to be done than there is > time to do it. There are more things to reach consensus on than there is > time to discuss. Also, there is also the risk of perpetuating an unhealthy > "us-vs-them" mentality which seems to underly this plan and this post. > > Instead (or perhaps simultaneously while you explore this plan) why don't > we try to address the community involvement problem? > > The big problem, I think, is that community members are directed to > es-discuss and yet es-discuss has been largely been abandoned by TC39 > committee members. Why has es-discuss been abandoned? There are a couple > of reasons I think: > > 1. Github (and their "issues" feature) has turned out to be a much better > platform for working out design details on particular proposals. Community > members have successfully and productively participated in the design > process in this way. > 2. The signal-to-noise ratio here is *really* bad these days. Let's be > honest: most of the strawman proposals that are brought here are pretty > terrible. It takes time to review and comment on even the worst ones, and > that's time that I (for one) would rather spend doing other things, like > working on observables, or cancel tokens, or private state, or async > generators, or drinking eine bier. > > The other problem that I've heard mentioned is that certain high-profile > proposals (like that function-pipe one) aren't getting any traction. > > First, there are *very* few proposals that fit into that category. Claude > Pache's https://github.com/claudepache/es-optional-chaining is great! In > general though, if a proposal isn't getting picked up it's probably because > either it has significant issues that committee members don't like, or the > time for it just isn't right. Time is a limiting factor and we have many > proposals working through the process already. > > I'll spend some time thinking about how we can improve the es-discuss > involvement problem. Thanks again for bringing attention to it! > > > On Thu, May 26, 2016 at 8:06 AM G. Kay Lee < > balancetraveller+es-disc...@gmail.com> wrote: > >> (This is a continuation of [a previous discussion]( >> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues >> )) >> >> So, to summarize, while rules and platforms currently in place do allow >> for community contributions, they are hardly friendly ones. A few issues: >> >> * The mailing list is a really awkward platform for community >> participants to collaborate, especially when debates and discussions can >> span months, even years; threads, reasonings, and important conclusions >> tend to become buried over time, resulting in a never-ending reincarnation >> of dead ideas and, more importantly, lose of precious lores and insights. >> >> * Self-contradictory rules about the processing of community proposals in >> official documents, because these rules were [authored by a few different >> individuals without a definitive source]( >> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues#content-17 >> ). >> >> * The most widely circulated version of these rules demands community >> proposals to find "champions", ie. member representatives willing to serve >> as lobbyists; the real story, however, is that member representatives are >> very busy and, when they do have time, they will almost always lobby for >> proposals that their organizations or themselves are interested in. No >> blaming here because this is just the way human society works, which brings >> the conclusion that this requirement is simply antihuman. >> >> In the previous discussion, Allen mentioned that a lot of efforts have >> already been put in place to make TC39 as open as possible under the bylaws >> and rules of Ecma International, for which I am sure every non-member >> participant of the standardization process is really appreciated. But I >> think there is still room to do better. >> >> For that reason I intend to form a nonprofit organization and apply for >> Ecma membership to help further opening up the standardization process of >> ECMAScript to interested participants who currently do not enjoy the >> privilege of becoming member representatives. >> >> I've been in contact with Secretary General Istvan and apparently this is >> doable as long as the General Assembly vote in favor of my application, so >> I th
Re: A plan to help TC39 become more open up to community contributions and participations
Thanks for pointing out some issues with the current state of things. While, in general, having more people directly participate in the committee is probably a good thing, I don't think that will fix the problem. I think you'll find yourself running into the same troubles that the current members face. Specifically, there is more work to be done than there is time to do it. There are more things to reach consensus on than there is time to discuss. Also, there is also the risk of perpetuating an unhealthy "us-vs-them" mentality which seems to underly this plan and this post. Instead (or perhaps simultaneously while you explore this plan) why don't we try to address the community involvement problem? The big problem, I think, is that community members are directed to es-discuss and yet es-discuss has been largely been abandoned by TC39 committee members. Why has es-discuss been abandoned? There are a couple of reasons I think: 1. Github (and their "issues" feature) has turned out to be a much better platform for working out design details on particular proposals. Community members have successfully and productively participated in the design process in this way. 2. The signal-to-noise ratio here is *really* bad these days. Let's be honest: most of the strawman proposals that are brought here are pretty terrible. It takes time to review and comment on even the worst ones, and that's time that I (for one) would rather spend doing other things, like working on observables, or cancel tokens, or private state, or async generators, or drinking eine bier. The other problem that I've heard mentioned is that certain high-profile proposals (like that function-pipe one) aren't getting any traction. First, there are *very* few proposals that fit into that category. Claude Pache's https://github.com/claudepache/es-optional-chaining is great! In general though, if a proposal isn't getting picked up it's probably because either it has significant issues that committee members don't like, or the time for it just isn't right. Time is a limiting factor and we have many proposals working through the process already. I'll spend some time thinking about how we can improve the es-discuss involvement problem. Thanks again for bringing attention to it! On Thu, May 26, 2016 at 8:06 AM G. Kay Lee < balancetraveller+es-disc...@gmail.com> wrote: > (This is a continuation of [a previous discussion]( > https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues > )) > > So, to summarize, while rules and platforms currently in place do allow > for community contributions, they are hardly friendly ones. A few issues: > > * The mailing list is a really awkward platform for community participants > to collaborate, especially when debates and discussions can span months, > even years; threads, reasonings, and important conclusions tend to become > buried over time, resulting in a never-ending reincarnation of dead ideas > and, more importantly, lose of precious lores and insights. > > * Self-contradictory rules about the processing of community proposals in > official documents, because these rules were [authored by a few different > individuals without a definitive source]( > https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues#content-17 > ). > > * The most widely circulated version of these rules demands community > proposals to find "champions", ie. member representatives willing to serve > as lobbyists; the real story, however, is that member representatives are > very busy and, when they do have time, they will almost always lobby for > proposals that their organizations or themselves are interested in. No > blaming here because this is just the way human society works, which brings > the conclusion that this requirement is simply antihuman. > > In the previous discussion, Allen mentioned that a lot of efforts have > already been put in place to make TC39 as open as possible under the bylaws > and rules of Ecma International, for which I am sure every non-member > participant of the standardization process is really appreciated. But I > think there is still room to do better. > > For that reason I intend to form a nonprofit organization and apply for > Ecma membership to help further opening up the standardization process of > ECMAScript to interested participants who currently do not enjoy the > privilege of becoming member representatives. > > I've been in contact with Secretary General Istvan and apparently this is > doable as long as the General Assembly vote in favor of my application, so > I think it's a good thing to raise this plan here and see if anyone has any > good feedbacks or concerns, so we can iron out these issues during the > early stage - or put an early end to it if there are some good reasons. A > legally registered nonprofit with an official "tax exemption" status is the > acceptance criteria for Ecma NFP members, but also requires me to go >
Re: Error-Type Specific try/catch Blocks
Shiny... On Fri, May 27, 2016, 05:06 Arthur Stolyar wrote: > Something wrong with prev link. > https://github.com/zenparsing/es-typed-catch > On May 27, 2016 12:00, "Arthur Stolyar" wrote: > >> If something, here seems to be another similar proposal: >> https://github.com/zenparsing/es-typed-catch >> > ___ > 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: Suggestion: "Object.hasOwnProperty"
I'd, for ergonomic reasons, would prefer it on Reflect. I very frequently alias this function, so having it as a static method on Reflect would be nice. On Thu, May 26, 2016, 17:42 doodad-js Admin wrote: > >> This would break a Web, a I have seen code that relies on > Object.hasOwnProperty === Object.prototype.hasOwnProperty > > Sorry, I didn’t remember that the constructor inherits it. > > >> Anyway, it would be handy to have such function as `Reflect.hasOwn` or > something like that. > > Yeah, maybe that then. Or “System.ObjectHasOwn” or else. > > Thanks > ___ > 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: es-discuss Digest, Vol 111, Issue 83
Try sending it with `unsubscribe` as the subject and no text. Or you could always go to the link and do it from there. ;-) On Thu, May 26, 2016, 16:28 Will wrote: > unsubscribe > > On Thu, May 26, 2016 at 4:21 PM, wrote: > >> Send es-discuss mailing list submissions to >> es-discuss@mozilla.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://mail.mozilla.org/listinfo/es-discuss >> or, via email, send a message with subject or body 'help' to >> es-discuss-requ...@mozilla.org >> >> You can reach the person managing the list at >> es-discuss-ow...@mozilla.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of es-discuss digest..." >> >> Today's Topics: >> >>1. Re: Observing whether a function is strict (Claude Pache) >>2. Reflect.create() (even stensberg) >>3. Suggestion: "Object.hasOwnProperty" (doodad-js Admin) >>4. Re: Reflect.create() (Bergi) >> >> >> -- Forwarded message -- >> From: Claude Pache >> To: Mark Miller >> Cc: "Mark S. Miller" , es-discuss < >> es-discuss@mozilla.org> >> Date: Thu, 26 May 2016 17:55:13 +0200 >> Subject: Re: Observing whether a function is strict >> >> Le 26 mai 2016 à 17:02, Mark Miller a écrit : >> >> I don't get it. What is being removed? >> >> >> A way to observe (almost surely?) that a given ECMAScript function is >> strict. >> >> What purpose does this accomplish? >> >> >> As I've said, maybe nothing to care about. That strange capability of >> `Function#arguments` just presented itself to my mind, and I really didn’t >> thought whether that has any consequence. >> >> —Claude >> >> >> >> On Thu, May 26, 2016 at 4:03 PM, Claude Pache >> wrote: >> >>> >>> Le 26 mai 2016 à 13:23, Mark S. Miller a écrit : >>> >>> >>> >>> On Thu, May 26, 2016 at 11:25 AM, Claude Pache >>> wrote: >>> > Le 26 mai 2016 à 10:43, G. Kay Lee < balancetraveller+es-disc...@gmail.com> a écrit : > > I was under the impression that strict mode is a (temporary) workaround to get rid of unwanted bad parts of the language without instantly breaking anything. The long term question thus should be: do we have a timeline on the final removal of non-strict behavior from the language, and establish the "strict mode" as the one and only standard behavior. If so, then introducing any additional language feature to help detecting strict/non-strict is certainly not ideal. AFAIK, there is no plan to remove non-strict mode. And to be clear about my intentions, what I have in the back of my head was certainly not "introducing any additional language feature to help detecting strict/non-strict" (yuck!), but whether it makes sense to think about a possible way to remove that leak from `Function#arguments` and `Function#caller`. But it would be premature to consider that issue without *at least* an answer to my original question: Are there other ways...? >>> >>> Hi Claude, what do you mean by "remove that leak"? Hypothetically, let's >>> say you had such a test and that it was reliable. How would you use it >>> remove the leak? (This is probably also the best way to clarify what >>> precisely you mean by removing the leak.) >>> >>> >>> Maybe that "leak", namely observing whether a function is strict, is not >>> something to care about. >>> >>> But here is what I think to be a possible way to remove it: Because >>> `Function#arguments` and `Function#caller` do return `null` for sloppy >>> functions in some circumstances (namely, when the function is not found in >>> the call stack), let them always return `null` for non-sloppy functions. >>> >>> —Claude >>> >>> >>> ___ >>> es-discuss mailing list >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> Cheers, >> --MarkM >> >> >> >> >> -- Forwarded message -- >> From: even stensberg >> To: es-discuss >> Cc: >> Date: Thu, 26 May 2016 19:42:10 +0200 >> Subject: Reflect.create() >> Before going further, please note that feedback will be on Github, since >> we want to avoid spamming in ES Discuss in order to provide a much cleaner >> system. >> >> I wrote up a draft about how I'd like this to look at: >> https://github.com/ev1stensberg/proposal-reflect-or, please note that I >> humbly accept any changes or opinions of this via Github, not here. This is >> because ES-Discuss is a bit messy when it comes to feedback, I.E that I get >> a mail every 30th minute of a one line comment. If it's absolutely >> necessary, drop a comment here, but I strongly advice you to try out GitHub >> issues. >> >> >> >> >> -- Forwarded message -- >> From: doodad-js Admin >> To: >> Cc: >> Date: Thu, 26 May 2016 15:26:52 -0400 >> Subject: Suggestion: "Object.hasOwnProperty" >> >> Hi, >> >> >> >> I think to create "Object.hasOwn
Re: Import wildcards
With this syntax, you would not be able to statically tell whether a
particular variable name (e.g. API_FOO) is bound to a module import,
without also analyzing the dependencies (and perhaps their dependencies).
These considerations killed the original "import all" syntax. (`import *
from 'foobar'`);
If repitition is an issue, use the namespace import form.
import * as constants from 'config';
On Fri, May 27, 2016 at 10:00 AM Maël Nison wrote:
> Hi,
>
> In about every project I have, I write a file or two with this form:
>
> export let API_USERNAME = `name`
> export let API_TOKEN = `token`
> // etc
>
> Most of the time, when I need one of those variables somewhere, I also
> need the other. It might be burdensome, since I end up with something
> similar to this:
>
> import { API_USERNAME } from 'config';
> import { API_TOKEN } from 'config';
> // etc
>
> Of course, I can import all of these token in a single line, but it
> doesn't help readability when there is a lot of entries (we all know that
> configuration files always end up with a fair number of variables - and
> let's not talk about parsers and similar). Plus, it's not very fun to
> explicitely write all these names when I just want to tell the engine that
> I will need everything similar, pretty please.
>
> Now as for the request: what would you think about adding a new syntax
> -nothing too fancy- to import all the symbols that match a *static *pattern?
> In the spirit of the `export * from ...` syntax, I feel like the following
> could be interesting:
>
> import { API_* } from 'config';
>
> As for the bad part: there really isn't, actually. This syntax is familiar
> with every developer that used globing before, and gives just enough
> insight to someone looking at the source code to understand that a variable
> named `API_SOMETHING` has been imported from a parent module. Linters would
> also be able to help in this regard, since they would just have to
> blacklist declaring variables that would conflict with an import prefix.
>
> Any thoughts ?
>
> ___
> 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
Import wildcards
Hi,
In about every project I have, I write a file or two with this form:
export let API_USERNAME = `name`
export let API_TOKEN = `token`
// etc
Most of the time, when I need one of those variables somewhere, I also need
the other. It might be burdensome, since I end up with something similar to
this:
import { API_USERNAME } from 'config';
import { API_TOKEN } from 'config';
// etc
Of course, I can import all of these token in a single line, but it doesn't
help readability when there is a lot of entries (we all know that
configuration files always end up with a fair number of variables - and
let's not talk about parsers and similar). Plus, it's not very fun to
explicitely write all these names when I just want to tell the engine that
I will need everything similar, pretty please.
Now as for the request: what would you think about adding a new syntax
-nothing too fancy- to import all the symbols that match a *static *pattern?
In the spirit of the `export * from ...` syntax, I feel like the following
could be interesting:
import { API_* } from 'config';
As for the bad part: there really isn't, actually. This syntax is familiar
with every developer that used globing before, and gives just enough
insight to someone looking at the source code to understand that a variable
named `API_SOMETHING` has been imported from a parent module. Linters would
also be able to help in this regard, since they would just have to
blacklist declaring variables that would conflict with an import prefix.
Any thoughts ?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Error-Type Specific try/catch Blocks
Something wrong with prev link. https://github.com/zenparsing/es-typed-catch On May 27, 2016 12:00, "Arthur Stolyar" wrote: > If something, here seems to be another similar proposal: > https://github.com/zenparsing/es-typed-catch > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Error-Type Specific try/catch Blocks
If something, here seems to be another similar proposal: https://github.com/zenparsing/es-typed-catch ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
