Re: How to solve this basic ES6-module circular dependency problem?

You could also swap that around to simplify the logic in the individual classes, e.g. ``` // --- Module A import C, {initC} from './c'; initC(); console.log('Module A', C) class A extends C { // ... } export {A as default} ``` then export that function to force-initialize the `C`

Re: How to solve this basic ES6-module circular dependency problem?

I found a solution that works in environments compiled by Babel, using the [workaround suggested by Ben Newman](https://github.com/ meteor/meteor/issues/7621#issuecomment-238992688): ```js // --- Module A import C from './C' let A = A // @benjamn's workaround applied export function setUpA(C)

The Invariants of the Essential Methods are false in case of reentrancy

In depends on what observing means. In this "inception" kind of observing, you could argue that the property hasn't yet been observed because [[Get]] was called before. ___ es-discuss mailing list es-discuss@mozilla.org

Re: Object.freezing proxies should freeze or throw?

Only in a Github issue please :-) we shouldn't be using bugs.ecmascript.org for new issues. On Wed, Aug 10, 2016 at 1:50 AM, Tom Van Cutsem wrote: > Thanks Claude for your careful review, and for trying to articulate a more > general principle behind the invariant checks.

Re: How to solve this basic ES6-module circular dependency problem?

Bradley, thanks! Based on what you've pointed out, if the entrypoint imports only B from module B, then that should cause the import lookup to go to module C, which sees the import for A and causes the lookup to go to module A, and finally depth first executes A, then C, then finally B. This is

Fwd: How to solve this basic ES6-module circular dependency problem?

-- Forwarded message -- From: Bradley Meck Date: Wed, Aug 10, 2016 at 3:05 PM Subject: Re: How to solve this basic ES6-module circular dependency problem? To: /#!/JoePea > Bradley, true, but C is also child of A, so it can also make

Re: Operating with arbitrary timezones

@Jordan, thanks a lot! Switching to a personal account then. @Tab other people in this thread have explained this throughly, but in essence answering certain questions about dates require knowing thetimezone offset. For example knowing when "yesterday" was in an arbitrary timezone is not just a

Re: How to solve this basic ES6-module circular dependency problem?

Aha, when using my setup functions, rollup.js tries to evaluate C first, in which case the *hoisted* functions are available, but A is not declared yet. I don't think that this would happen in real ES6 modules (no hoisting like that). */#!/*JoePea On Wed, Aug 10, 2016 at 12:55 PM, /#!/JoePea

Re: How to solve this basic ES6-module circular dependency problem?

Isiah, here's the [rollup.js result](http://goo.gl/jl1B8H) using my setup functions technique. When I paste the result in my console it complains that A is undefined inside the `setUpA` function, which seems odd. Here's the [result of my original code](http://goo.gl/cbjVOi) (similar to your

Re: How to solve this basic ES6-module circular dependency problem?

Please note that in https://tc39.github.io/ecma262/#sec-moduleevaluation , Modules evaluate their children prior to evaluating themselves (15.2.1.16.5.6.c) , C should never be evaluate before A or B in this dep graph. On Wed, Aug 10, 2016 at 2:41 PM, /#!/JoePea wrote: > Oh! And

Re: How to solve this basic ES6-module circular dependency problem?

What do you get out of Rollup.js (which actually implements the ES6 spec with bindings, unlike Webpack, etc., which handle CommonJS modules)? You should be able to run the bundled repro in Node, or you could inspect the bundle yourself just as easily to see the execution order. On Wed, Aug 10,

Re: How to solve this basic ES6-module circular dependency problem?

Isaiah, also note that ```js export default class Foo {} ``` does not create a live binding that can be modified at a later point in time, which is the feature that my `setUpA` and `setUpB` functions are theoretically relying on (and which I believe the Meteor and Webpack environments don't

Re: How to solve this basic ES6-module circular dependency problem?

In your module B, `class B` should `extends C` instead of A, so both classes `A` and `B` extend from `C`. I made a reproduction that you can run (assuming you have Meteor installed). See the following with instructions: https://github.com/meteor/ meteor/issues/7621#issuecomment-238923360 But,

Re: Function constants for Identity and No-op

Those spellings don't help when trying to visually parse a bunch of code which already largely consists of dense punctuation, though, IMO. On Wednesday, 10 August 2016, Tab Atkins Jr. wrote: > On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman wrote: > Now obviously it would be trivial for me to declare these constants in > userland code like I already do, e.g. `const NOOP = () => {}`, but in > projects where it's needed in several files, I'll have to put that in a >

Re: Function constants for Identity and No-op

Kevin that "from somewhere else" has same problems cross-realm `instanceof` would have, you can't always trust that and if you want to map identities just do it instead of adding extra code ;-) On Wed, Aug 10, 2016 at 5:24 PM, Kevin Reid wrote: > [no quotes because I'm not

Re: Function constants for Identity and No-op

[no quotes because I'm not replying to anyone in particular] An advantage that has not been mentioned yet, of having a canonical function instance for particular behaviors, is that it allows for some library-level optimization by being able to know what a function does (which is otherwise

Re: Function constants for Identity and No-op

> On Aug 10, 2016, at 8:46 AM, Peter van der Zee wrote: > > There is precedent (at least in IE [1]) for exotic functions where > `typeof` returned "unknown". Could happen for any exotic value unless > >>the spec changed on that<<. see

Re: Function constants for Identity and No-op

Function.isFunction was a joke, I'm pretty sure that only very old legacy code deals with document.all and crazy stuff like that (however, it would be useful, but saving me from typing few more characters isn't something urgent or important). On 10 Aug 2016 5:46 p.m., "Peter van der Zee"

The Invariants of the Essential Methods are false in case of reentrancy

Test case: ```js var results = [] var observe = function (method, object, ...args) { results.push({ method: method , object: object , args: args , output: Reflect[method](object, ...args) }) } var obj = { get x() { Object.defineProperty(this, 'x', { value:

Re: Adding DOTALL modifier to ECMAScript regex standards

My response bounced back to me, not sure if it went through. I agree, I doubt functionality in IE8- will matter, but I was thinking it would be nice to align the regex modifiers with other languages for the future. *Java:* https://docs.oracle.com/javase/7/docs/api/java/util/

Re: Function constants for Identity and No-op

>> What's the issue with document.createElement('object')? > It's a callable exotic object. >> Function.isFunction? :D > typeof is what you are looking for. There is precedent (at least in IE [1]) for exotic functions where `typeof` returned "unknown". Could happen for any exotic value unless

Object.freezing proxies should freeze or throw?

A relevant github issue regarding [[OwnPropertyKeys]] is https://github.com/tc39/ecma262/issues/461 . I also wish [[OwnPropertyKeys]] didn't allow duplicates. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 7:33 AM, Mark S. Miller wrote: > > > On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman wrote: > >> I can understand the sentiment of wanting brevity and avoiding >> unnecessary abstraction, but in some cases I think it comes at the

Re: Function constants for Identity and No-op

I agree with Mark here plus we have const now which is perfect for something like this if you wanted to take DRY to an extreme. Ultimately seeing a function declared is obvious, seeing a special key word is not. I have been in software development close to 15 years now and when I first saw this I

RE: Function constants for Identity and No-op

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Mark S. Miller > What's the issue with document.createElement('object')? It's a callable exotic object. >> On Wed, Aug 10, 2016 at 7:20 AM, Michał Wadas >> wrote: >> Function.isFunction? :D

Re: Adding DOTALL modifier to ECMAScript regex standards

I agree, I doubt functionality in IE8- will matter, but I was thinking it would be nice to align the regex modifiers with other languages for the future. *Java:* https://docs.oracle.com/javase/7/docs/api/java/util/regex/Pattern.html#DOTALL *Python:*

Re: Adding DOTALL modifier to ECMAScript regex standards

On Wed, Aug 10, 2016 at 4:40 PM, Bob Myers wrote: > If it's any consolation there is the more compact hack of `[^]`, which I > **think** is supposed to work everywhere. That doesn’t work in IE < 9, but that shouldn’t matter in 2016. ___

Re: Adding DOTALL modifier to ECMAScript regex standards

If it's any consolation there is the more compact hack of `[^]`, which I **think** is supposed to work everywhere. On Wed, Aug 10, 2016 at 3:02 PM, Jake Reynolds >> wrote: >> >>> In ECMAScript the only current way to make a match like that work is to >>> use [\d\D] which

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 7:25 AM, Eli Perelman wrote: > I can understand the sentiment of wanting brevity and avoiding unnecessary > abstraction, but in some cases I think it comes at the cost of readability > or good practice. This is why variables exist at all: to store

Re: Function constants for Identity and No-op

FWIW, I just use `Object` most of the time as both no-op and identity (beside primitives, but I rarely have primitives on callback arguments where I need the no-op). I agree with Mark arrow makes everything ever more explicit and allocation is an engine concern, something that could even not ever

Re: Ignoring arguments

Confused by this thread. > What if you could use a `.` as a wildcard? You can already use `_` or anything you want, as was already pointed out in early iterations of this idea. > it would avoid binding a usable identifier. What is the problem with that? What is the problem that this proposal

Re: Function constants for Identity and No-op

I can understand the sentiment of wanting brevity and avoiding unnecessary abstraction, but in some cases I think it comes at the cost of readability or good practice. This is why variables exist at all: to store commonly used values either for reuse or to cut down on unnecessary allocation.

Re: Function constants for Identity and No-op

What's the issue with document.createElement('object')? On Wed, Aug 10, 2016 at 7:20 AM, Michał Wadas wrote: > Using instanceof Function can be confusing, because there are objects > that are callable but not instanceof Function (document.all, >

Re: Function constants for Identity and No-op

Using instanceof Function can be confusing, because there are objects that are callable but not instanceof Function (document.all, document.createElement('object'), any cross-realm function). Function.isFunction? :D On Wed, Aug 10, 2016 at 4:00 PM, Mark S. Miller wrote: > >

Re: Ignoring arguments

What if you could use a `.` as a wildcard? I don’t think it would conflict with existing syntax, and it would avoid binding a usable identifier. It would be more obvious than nothing between the commas. > On Aug 8, 2016, at 06:33, Cyril Auburtin wrote: > > Just

Re: Adding DOTALL modifier to ECMAScript regex standards

Correct, sorry about that. I should have verified in a regexr before typing up the examples. On Wed, Aug 10, 2016 at 9:12 AM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > Just to double check, your `/he[\d\D]?llo/` should be `/he[\d\D]*?llo/`, > right? > Otherwise it's not the same

Re: Adding DOTALL modifier to ECMAScript regex standards

Just to double check, your `/he[\d\D]?llo/` should be `/he[\d\D]*?llo/`, right? Otherwise it's not the same as `/he[.*]?llo/` On Wed, Aug 10, 2016 at 3:02 PM, Jake Reynolds wrote: > Hello, > > I brought up the topic of adding the DOTALL modifier to the Chrome V8 >

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 2:10 AM, Isiah Meadows wrote: > I'll note that it's longer than just typing them out manually (and close > if they're aliased): > > ```js > Function.IDENTITY > IDENTITY > x => x > > Function.NOOP > NOOP > () => {} > ``` > > Not sure if it adds

Adding DOTALL modifier to ECMAScript regex standards

Hello, I brought up the topic of adding the DOTALL modifier to the Chrome V8 Engine here and was directed to es-discuss. I was curious about the practicality and the want for adding a DOTALL modifier to the

Re: Function constants for Identity and No-op

On Wed, Aug 10, 2016 at 4:53 AM, Andy Earnshaw wrote: > On Wed, 10 Aug 2016 at 12:42 Michał Wadas wrote: > >> Function.prototype is no-op (run Function.prototype.toString() for more >> information) >> > > That's true, but using `Function.prototype`

Re: Function constants for Identity and No-op

On Wed, 10 Aug 2016 at 12:42 Michał Wadas wrote: > Function.prototype is no-op (run Function.prototype.toString() for more > information) > That's true, but using `Function.prototype` can be confusing when passed to a function as a callback:

Re: Function constants for Identity and No-op

Function.prototype is no-op (run Function.prototype.toString() for more information) On Wed, Aug 10, 2016 at 12:03 PM, Tiddo Langerak wrote: > I think this is more about improving readability than saving a few > characters. > > > On 08/10/2016 11:10 AM, Isiah Meadows

Re: Function constants for Identity and No-op

I think this is more about improving readability than saving a few characters. On 08/10/2016 11:10 AM, Isiah Meadows wrote: I'll note that it's longer than just typing them out manually (and close if they're aliased): ```js Function.IDENTITY IDENTITY x => x Function.NOOP NOOP () => {} ```

Re: Ignoring arguments

Okay. I'll admit I'm wrong here. I misremembered. I knew they were more of a legacy thing, I just didn't know they were available in strict mode. On Wed, Aug 10, 2016, 05:37 Claude Pache wrote: > Le 10 août 2016 à 11:01, Isiah Meadows a écrit : >

Re: How to solve this basic ES6-module circular dependency problem?

First of all, I'll point out that even if it's an internal API, you should just initialize them immediately. You already have an otherwise fully initialized C, so you should just add them whenever it comes. You shouldn't need a `setUpA` export, especially called by one of its dependencies. Just

Re: Ignoring arguments

> Le 10 août 2016 à 11:01, Isiah Meadows a écrit : > > For what it's worth, elided array elements aren't available in strict mode > Are you sure? —Claude ___ es-discuss mailing list es-discuss@mozilla.org

Re: Function constants for Identity and No-op

I'll note that it's longer than just typing them out manually (and close if they're aliased): ```js Function.IDENTITY IDENTITY x => x Function.NOOP NOOP () => {} ``` Not sure if it adds anything. On Tue, Aug 9, 2016, 14:44 Eli Perelman wrote: > I'm not sure if something

Re: Ignoring arguments

For what it's worth, elided array elements aren't available in strict mode (they're a syntax error), and it's not likely anyone is going to want to add a new sloppy mode only feature. Plus, it's not easy to tell at a glance if it's a typo or intentional. `Math.min(x,,y)` is a likely error, but a

Re: Object.freezing proxies should freeze or throw?

Thanks Claude for your careful review, and for trying to articulate a more general principle behind the invariant checks. The lack of such crisp principles makes it (too) difficult to verify whether all necessary checks are in place. To clarify, in the case of "update" MOP operations such as

Re: How to solve this basic ES6-module circular dependency problem?

When I try this same code with Webpack, I get the *exact same results*: the `console.log` statements in the exact same order, where the last output shows that `A` in the entry point is `undefined`). Am I misunderstanding something about live bindings? Is there some guaranteed order in which these

Re: How to solve this basic ES6-module circular dependency problem?

I can get the whole thing to work if I pass the C dependency into the `setUpA` and `setUpB` functions as follows, but oddly `A` is `undefined` in the Entrypoint module at the `console.log` statement, which makes it seem to me like live bindings aren't working the I was expecting. ```js // ---