The only reason I've used `__noSuchProperty__` name in that example was to
indeed remind `__noSuchMethod__` and others anti-name-clashing old patterns
we all know but basically I was trying to explain that composing instead of
extending is a win for these kind of magic behaviors.
It is possible
Tab Atkins Jr. wrote:
I don't understand how you inferred from Andrea's post that this
wish-fulfillment __noSuchProperty__ magic property does not have to
handle superclass delegation..
I did not infer that from Andrea's post as his position -- rather the
reverse, because he said I also think
On Fri, Sep 26, 2014 at 10:29 AM, Brendan Eich bren...@mozilla.org wrote:
Tab Atkins Jr. wrote:
I don't understand how you inferred from Andrea's post that this
wish-fulfillment __noSuchProperty__ magic property does not have to
handle superclass delegation..
I did not infer that from
Dean Landolt wrote:
Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
No, but O.o has its own costs. See
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
/be
On Fri, Sep 26, 2014 at 5:01 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
On Thu, Sep 25, 2014 at 6:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
It's still there.
js var anObject = { __noSuchMethod__() { return what; } };
js
Can I import module dynamically, but synchronously? Example for common js
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
In es6 draft I found that ModuleSpecifier must be a StringLiteral
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
no.
On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov ikokos...@gmail.com
wrote:
Can I import module dynamically, but synchronously? Example for common js
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
In es6 draft I found that ModuleSpecifier must be a
And the reason you cannot import a module synchronously is that it would
freeze the entire browser until the http request completes, which could be
several seconds on a slow internet connection.
If you want to import something dynamically you can do it using the API (to
be finalized, I believe):
Brendan Eich wrote:
Dean Landolt wrote:
Out of curiosity, wouldn't Object.observe require implementors to add
precisely this kind of hook into the vm anyway?
No, but O.o has its own costs. See
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
To say a bit more,
Konstantin Ikonnikov wrote:
Can I import module dynamically, but synchronously? Example for common js
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
You can't do that in the browser, as followups point out. Do you use
browserify or similar to make this seem to work? If so,
Dean Landolt wrote:
http://lists.w3.org/Archives/Public/public-script-coord/2014JulSep/0204.html
Sure, O.o isn't free, and I get that using @noSuchProperty would
likely result in all kinds of deoptimization. But of all the costs
listed in that thread, I'm not seeing any mention of the
I don't want load module using http request. In my case module already
defined and I want import it later when I get its name:
```js
var moduleName = getModuleName();
import { foo } from moduleName;
// use foo
```
2014-09-26 20:00 GMT+04:00 Marius Gundersen gunder...@gmail.com:
And the
Brendan Eich wrote:
A general-purpose (as its name implies) nSP would hit lookup (get as
well as set) paths, not just mutation (set). But it seems Andreas's
just to clear up some myths words were missed, even considering only
mutation (not notification).
From private correspondence with
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
would not work in browserify either
On Fri, Sep 26, 2014 at 12:40 PM, Konstantin Ikonnikov ikokos...@gmail.com
wrote:
I don't want load module using http request. In my case module already
defined and I want import it later when
On Thu, Sep 25, 2014 at 5:38 PM, Brendan Eich bren...@mozilla.org wrote:
On Sep 25, 2014, at 7:56 PM, Boris Zbarsky bzbar...@mit.edu wrote:
SpiderMonkey used to support __noSuchMethod__, I believe.
I implemented __noSuchMethod__ long ago, for the TIBET folks (Smalltalk style
JS framework;
```js
var moduleName = 'foo';
var foo = require(moduleName);
```
would not work in browserify either
It does work in browserify, but you need to be sure to include it in a list
of requires if it is not imported by the current list of files statically
(ala `browserify -e main.js -r foo`).
true and by that same token it is possible to use the loader api to get
similar results out of ES6 modules (
https://github.com/calvinmetcalf/es6-translate)
On Fri, Sep 26, 2014 at 3:46 PM, Bradley Meck bradley.m...@gmail.com
wrote:
```js
var moduleName = 'foo';
var foo =
Theoretically you can use System.normalize() and System.get() to lookup a
module by name synchronously. The normalize feature requires a referrer or
address.
Since browsers are determined to eliminate synchronous scripts, you may as
well deal with the asynchronous System.import() and obnoxious
Tab Atkins Jr. wrote:
Any nSP of the kind we seem to be discussing would need to fail fast, on
evaluation of the dot expression. That is a fast path.
I, personally, have only ever used Python and PHP's nSP functionality
to implement methods. Most of the fancy uses I see for it in, say,
Ruby
Now that JS is growing an event loop, what should happen to it in
navigated-away-from windows?
To make this concrete:
1) Say I have an object that came from such a window and it has an
Object.observe observer on it that mutates the property being observed.
Should this continue to run
20 matches
Mail list logo
