On Sat, Sep 27, 2014 at 4:03 AM, Boris Zbarsky wrote:
> Now that JS is growing an event loop, what should happen to it in
> navigated-away-from windows?
I still don't understand why JavaScript needs to have the loop itself
and can't just queue jobs for the Host to take care of. Given that the
Hos
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 foreve
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 (
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 pro
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
wrote:
> > ```js
> > var moduleName = 'foo';
> > var foo = require(moduleName);
> > ```
> >
>
> ```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`
On Thu, Sep 25, 2014 at 5:38 PM, Brendan Eich wrote:
> On Sep 25, 2014, at 7:56 PM, Boris Zbarsky wrote:
>>
>> SpiderMonkey used to support __noSuchMethod__, I believe.
>
> I implemented __noSuchMethod__ long ago, for the TIBET folks (Smalltalk style
> JS framework; they wanted a doesNotUndersta
```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
wrote:
> 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:
>
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 De
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 :
> And the reason you cannot impor
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
On Fri, Sep 26, 2014 at 11:10 AM, 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
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, t
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,
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):
no.
On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov
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 StringLiteral
> http://p
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
___
On Fri, Sep 26, 2014 at 5:01 PM, Jason Orendorff
wrote:
> On Thu, Sep 25, 2014 at 6:56 PM, Boris Zbarsky wrote:
>> SpiderMonkey used to support __noSuchMethod__, I believe.
>
> It's still there.
>
> js> var anObject = { __noSuchMethod__() { return "what"; } };
> js> anObject.saysWhat();
> "what"
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 Thu, Sep 25, 2014 at 6:56 PM, Boris Zbarsky wrote:
> SpiderMonkey used to support __noSuchMethod__, I believe.
It's still there.
js> var anObject = { __noSuchMethod__() { return "what"; } };
js> anObject.saysWhat();
"what"
We did tweak the semantics last year (a minor improvement, I think):
On Fri, Sep 26, 2014 at 10:29 AM, Brendan Eich 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 Andrea's
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 thi
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
23 matches
Mail list logo