Re: Operating with arbitrary timezones

[Juan Ignacio Dopazo]

@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 matter of taking a date and removing 24 hours from it. This is
mostly a "presentation" issue, but not necessarily a "display" issue, which
is why I'm saying it's not just something that Ecma 402 covers.

Moment-js and Intl.DateTimeFormat do a good job at displaying dates, but in
order to do arithmetic on local dates we end up having to use them and
parse their return values.

It should be straightforward to implement a library with a TimeZone class,
same as what the ICU library has (http://icu-project.org/
apiref/icu4j/com/ibm/icu/util/TimeZone.html), based on the Unicode CLDR
data. But this does look like something EcmaScript should provide. The only
reason I haven't done it and published it is because we want to avoid
having to ship all that historical CLDR data to the browser.

On Tue, Aug 9, 2016 at 3:47 PM, Claude Pache  wrote:

>
> Le 8 août 2016 à 20:51, peter miller  a écrit :
>
> On Fri, 05 Aug 2016 22:30:28 +0100, Tab Atkins Jr. 
> wrote:
>
> Much of what follows is wanton pedantry, for which I apologise. ;)
>
> I would disagree. Time isn't useful without a point in space (space and
> time
> should be looked at as one thing, not two) and since the Date object tracks
> it internally as UTC it has a default space.
>
>
> This is incorrect. It tracks a UTC timestamp; the current time as I
> write this is 1470432591121 milliseconds since the epoch, and that's
> true regardless of where you are on the planet.
>
>
> I suspect you've dropped 36s from that count or used 1st January 1970 0h
> 0m 36s as your epoch.  I might be wrong. But if you have, it's because
> Universal Time is a "rotational timescale": it measures the angle of a
> fictitious point in the sky (U) relative to the prime meridian and not a
> linear count of seconds. The IERS (International Earth Rotation and
> Reference Systems Service) measures the angle of U and issue "Universal
> Time" (UT1). With UTC being kept within one second of UT1 via leap seconds
> (next one at the end of year).
>
> The value an observer measures for U, called UT0, really does depend on
> their exact position on the surface of the earth. That has to be adjusted
> for. That said, UT1/UTC are notionally the same for us all. And I know
> that's what you were saying. Like I said, I'm showing off my very hard won
> knowledge.
>
> And I might as well point out UT is defined on the earth's surface. It's
> affected by gravity.
>
> Timezones are a *display* concept - they affect how you parse
> human-readable strings into timestamps, and how you display a
> timestamp as a human-readable string.  This is similar to the
> distinction between Unicode values and strings encoded in UTF8.
>
>
> Sure, calendar dates (year, month and day) are a human-friendly way of
> displaying the number rotations of U over a meridian.
>
> But I think timezones represent a change in meridian. I believe in the
> olden days people would set their watches to a local meridian. (I'm reading
> Verne's _Mysterious_Island_ at the moment
> and it contains a reference to a chronometer set to the Washington
> meridian.)  And while the "timezones" we use in modern civil life are a
> political construct, I suspect a timezone is still saying display the
> transits of U over such-and-such a meridian; it's a shift in longitude, not
> directly a shift in time.
>
>
> As a final unrelated comment, I wonder whether 20.3.1.1 should explicitly
> define javascript time values to be:
>
> `d * 8640 + ms`
>
> Where `d` is the number of whole UTC days elapsed since midnight 1 January
> 1970 and `ms` is the number of milliseconds elapsed since the start of
> current UTC day, with the value of `ms` being implementation defined close
> to a leap second - and possibly diverging from thousandths of an SI second.
>
> I think that's what the existing standard is trying to say but the current
> phrasing feels wrong, and the above makes clear that timevalues are a
> construct used to represent UTC not a count of millseconds since epoch
> (which javascript dates can never be because they exclude the 36---soon to
> be 37---leap seconds).
>
> Peter
>
> PS: Can we not add underscores to numbers? Would allowing 86_400_000 break
> the web?
>
>
>
> Well, if you want to be pedantic...
>
> You should disregard the *non-normative* introduction text found in
> 20.3.1.1, which might be slightly imprecise:
>
> Time is measured in ECMAScript in milliseconds since 01 January, 1970 UTC.
> In time values leap seconds are ignored. It is assumed that there are
> exactly 86,400,000 milliseconds per day.
>
>
> and pay more attention to the *normative* definitions given in 20.3.1.2:

Re: Modules and dependencies known before the load

[Juan Ignacio Dopazo]

For prefetching we're calling LoadModule() for all the dependencies we want to 
prefetch in the Fetch or Locate hooks.
For example, Systemjs has a System.depCache option which allows you to define 
dependencies ahead of time. Here's the hook implementation: 
https://github.com/systemjs/systemjs/blob/master/lib/extension-depCache.js.
- Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 module syntax – done?

[Juan Ignacio Dopazo]

There was discussion about using `this` for exposing metadata about the module. 
For example (pure speculation):

this.address; // location of the current module
this.name; // name of the current module
this.metadata; // object with metadata generated during the loading lifecycle
this.loader // maybe? reference to the loader that actually loaded this module

-Juan


On Wednesday, August 6, 2014 3:31 PM, Axel Rauschmayer a...@rauschma.de wrote:
 


I haven’t seen any mention of `import * as foo` in the meeting notes, so I’m 
assuming that the ES6 module syntax is basically done. Right? Except for the 
“import-into-namespace syntax” [1], of course. As an aside, I’m really glad 
that `this` won’t be used here (which would have resulted in yet another thing 
one has to learn about `this`).
[1] 
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-07/jul-30.md#45-import-into-namespace-syntax-dave

-- 
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de




___
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: Loader vs ES6 Classes

[Juan Ignacio Dopazo]

In practice we've found that we rarely use the new Loader(hooks)` option and 
instead this is more common:

var loader = new Loader();
var loaderFetch = loader.fetch.bind(loader);

loader.fetch = function (loadRecord) {
  // do something
  return loaderFetch(loadRecord);
};

This way we can think of each modification to the loader in isolation and we 
can use the same code to modify a custom loader instance and to modify the 
System instance.


-Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[Juan Ignacio Dopazo]

 On Monday, August 4, 2014 11:48 AM, Axel Rauschmayer a...@rauschma.de wrote:

  On Aug 4, 2014, at 16:33 , John Barton johnjbar...@google.com wrote:

  As far as I can tell you are basically arguing that simple Loader hooks 
  don't need object state. Of course that is true.

 No, I’m arguing that Juan’s code is basically “subclassing” a loader, 
 overriding a method and calling that method. ES6 classes seem like a more 
 elegant way of doing this. You’d get as much object state in the subclass as 
 you want.


We are actually using state a lot for configuration. And there's ongoing 
discussion about how to do it. So far we've been extending the Loader instance 
with our own properties (e.g. loader.depCache = {}). The main reason is that we 
want our extensions to the loader to work both on new instances of the Loader 
class and on the System loader, which can't be subclassed.

Also, we want each of our extensions to the loader to be self-contained. The 
reason is that apps that have critical performance needs need to be able to 
pick the extensions they want instead of bundling everything in case they need 
them. Subclassing doesn't quite get along with this approach. We also expect 
performance critical applications to insert their loader extensions in the HTML 
page or to PUSH them using SPDY. This way, in browsers that have the Loader 
API, we avoid this situation:

Fetch HTML page - Fetch Loader extensions - Fetch the app's code

Some links to current discussion:

- Conditional loading configuration: 
https://github.com/systemjs/systemjs/issues/126
- Reconsidering extension process again: 
https://github.com/systemjs/systemjs/issues/158
- Package configuration: https://github.com/systemjs/systemjs/issues/141


-Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader locate/fetch/translate/instantiate API

[Juan Ignacio Dopazo]

I don't have an answer, but the metadata property of the loadRecord object 
was designed to be the place where you put your own custom metadata so that 
it's persisted across hooks. And it works in es6-module-loader: 
http://jsbin.com/kutey/2/edit?js,output.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Quantifying Default Exports

[Juan Ignacio Dopazo]

 On Saturday, July 19, 2014 1:53 PM, Brian Di Palma off...@gmail.com wrote:

 When an npm package exports a named identifier it's trivial to use it
in an ES6 module.

import {
    parse,
    print
} from 'recast';

 When on the other hand it sets its export on `module.exports` default
exports provide no help at all.

This sounds like an issue in your transpiler. Ideally CJS modules inside 
projects written using ES6 modules should be treated as modules that default 
export an object. CJS modules don't have the same static semantics as their ES6 
counterpart, so they should be treated as mutable objects. An ES6 Loader would 
do the same when loading CJS modules.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader Hooks

[Juan Ignacio Dopazo]

On Tuesday, June 24, 2014 11:38 AM, Calvin Metcalf calvin.metc...@gmail.com 
wrote:


Say you wanted to add a hook which automatically added an export named 
filepath to a module is the path to the file
For this use case and other similar ones it'd be nice if the `metadata` 
property of load records would be exposed as part of the modules metadata in 
`this` or `Reflect.currentModule()`.

or add an import just for the side effects (say a shim or something)
We've been discussing conditional loading for shims and other similar stuff at 
https://github.com/systemjs/systemjs/issues/9.

Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: TC39 vs the community

[Juan Ignacio Dopazo]

On Friday, June 20, 2014 7:15 PM, Andrea Giammarchi 
andrea.giammar...@gmail.com wrote:
 
typo ...

```
var require = function (fromWhere) {
  return  import * from fromWhere
};
```

That's not valid ES6. It's specified that:

- Import and export statements can only be top level statements
- The module name must be a string literal.
- Import * is not specified.

ES6 modules are designed to be static. So no, you can't use import statements 
under the hood in require(). But you can set up things so that you can use 
import to import CommonJS modules.

Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[Juan Ignacio Dopazo]

On Thursday, June 19, 2014 5:17 AM, David Herman dher...@mozilla.com wrote:

```js
import * as fs from fs; // importing the named exports as an object
import Dict from dict;  // importing a default export, same as ever
```


My first reaction is to think that a lot of developers will ask: why can't I do 
`import * from 'fs';`?

But it's easier to teach than the alternative. And I agree with the premises: 
ModuleImport should be there and it should be less convenient than using the 
default export.

Thanks David!

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 modules (sorry...)

[Juan Ignacio Dopazo]

There are two options for prefetching dependencies without having to wait for 
load and parse:

1) Assume none of your modules use the loader object for loading other modules, 
parse them during deployment and get the dependency graph.
2) Use what Guy calls a tracer that executes your app during development and 
stores the dependency graph as it goes, which takes into account calls to 
loader.import().

As for bundling but you can use loader.define() which takes the name of the 
module and its source code, ie:

System.define('module1', 'export var answer = 42;');
System.define('module2', 'export var answer = 43;');


There are a couple of issues around this though. The main issue is that you 
can't call System.define('foo', ...) during foo's import lifecycle. But I think 
these can be fixed.


Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ES6 modules (sorry...)

[Juan Ignacio Dopazo]

On Monday, June 16, 2014 12:33 AM, Axel Rauschmayer a...@rauschma.de wrote:


**Single-export modules.** Still missing is support for single-export modules, 
which could be added as follows (the keyword `default` instead of the asterisk 
works just as well, in my opinion).


You're being confused by CommonJS. ES6 modules don't have single-export 
modules. All modules can have multiple exports. And all modules can have a 
specially named export called default which allows you to skip the curly 
brackets.

Example:

// foo.js
export default function () { // anonymous function
  console.log(42);
}

// bar.js
import answer from 'foo'; // I can give whatever name I want to the default 
export
answer(); // 42


Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Imports and eval

[Juan Ignacio Dopazo]

That answer made me very happy. Thank you Allen!

Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Integrating the Webs' dependency systems

[Juan Ignacio Dopazo]

On Wednesday, May 28, 2014 7:27 PM, Ian Hickson i...@hixie.ch wrote:
One thing I don't see in the hooks above is anything to do with actually 
processing dependencies. How would I (at the spec level) tell the ES6 
module system that it should not evaluate a particular module until some 
non-script resource, e.g. a style sheet, is available?
When you create a dynamic module in the instantiate hook you can specify a list 
of dependencies like this:

System.instantiate = function (loadRecord) {
  return {
    deps: ['some', 'list', 'of', 'dependencies'],
    execute: function () {
      // return a new Module instance
    }
  };
};

The Loader will know to wait for those dependencies.


One thing about this is it seems very script-centric. It would be weird if 
every time there was a link rel=stylesheet in the document, we 
implicitly went through an ES6 module's instantiate hook just to fire up 
the style sheet. Is there some way we can make this more generic?


Yes, the System loader would be an API for imperatively loading stuff from a 
script. The Loader hooks are the way of exposing to the JS environment how the 
browser loads stuff.

This is interesting because users could actually modify the System loader. For 
example, they could set it up to load modules conditionally according to the 
browser's features. It could also be interesting to leave that door open for 
non-script imports also being subject to user rules.


Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Integrating the Webs' dependency systems

[Juan Ignacio Dopazo]

On Thursday, May 29, 2014 4:34 PM, Ian Hickson i...@hixie.ch wrote:


The contexts in which I am interested about this kind of thing
 is:


- some people want to predeclare a bunch of scripts and their 
   dependencies, without actually downloading any of them ahead of time, 
   and then later, when they're needed, have the entire tree downloaded 
   all at once. 

At the moment we're doing this by running static analysis tools on the ES6 
modules and using the information from the dependency tree to know how to 
download all of them at once.
- sometimes, even a file that is not downloaded immediately upon being 
   referenced by another file might still want to be precached, so that 
   when it _is_ needed, it's already locally available

The Loader object is actually a dictionary, so it acts as its own cache. You 
can call loader.fetch() yourself without
 the module being executed in order to cache it.

On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:

 The Loader will know to wait for those dependencies.



I'm having difficulty understanding the spec for the instantiate hook. 
Does it get called before the fetch hook? Is there some way to dynamically 
add dependencies later?
The lifecycle of a module request is normalize - locate - fetch - translate 
- instantiate. Instantiate doesn't actually execute anything until all of the 
dependencies have gone through the same 5 steps.





Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Integrating the Webs' dependency systems

[Juan Ignacio Dopazo]

On Thursday, May 29, 2014 6:31 PM, Ian Hickson i...@hixie.ch wrote:


On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
 
  - some people want to predeclare a bunch of scripts and their 
    dependencies, without actually downloading any of them ahead of time, 
    and then later, when they're needed, have the entire tree downloaded 
    all at once. 
 
 At the moment we're doing this by running static analysis tools on the 
 ES6 modules and using the information from the dependency tree to know 
 how to download all of them at once.


Right, it's relatively common for people to do this. Not just for scripts, 
indeed, but also for style sheets and other resources. Ideally the browser 
would take care of this logic for the author.
Yes. The author would still have to provide the dependency tree upfront (I 
wrote this for exactly this use case 
https://www.npmjs.org/package/module-graph) , but it's something that would be 
nice if the browser Loader did.
  
  - sometimes, even a file that is not downloaded immediately upon being 
    referenced by another file might still want to be precached, so that 
    when it _is_ needed, it's already locally available
 
 The Loader object is actually a dictionary, so it acts as its own cache. 
 You can call loader.fetch() yourself without the module being executed 
 in order to cache it.


The idea here is that the browser would be able to determine when it's 
best to preload the file; the author would just want to tell the UA that 
the file is something worth precaching, not actually do it.

I think this would get along well with the module tag. If the browser had an 
attribute that said if any remote resource (images, stylesheets, modules) may 
be preloaded, then it would just have to hook into loader.fetch() to tell the 
ES Loader that it already started preloading the module.

  I'm having difficulty understanding the spec for the instantiate hook. 
  Does it get called before the fetch hook? Is there some way to 
  dynamically add dependencies later?

 The lifecycle of a module request is normalize - locate - fetch - 
 translate - instantiate. Instantiate doesn't actually execute anything 
 until all of the dependencies have gone through the same 5 steps.




Aha, ok.


Is there a way to add dependencies before the fetch hook is called?


Not without jumping through some hoops. But the dependencies aren't really what 
matter at the fetch stage. You can fetch other resources, which will generate 
internal LoadRecords for them, without specifying they're dependencies.


When is the fetch hook called in the current ES6 logic? As soon as 
locate provides a URL?
Yes. It's promise based though. locate may even take time (we're using this 
to do the opposite of prefetching: generate a single HTTP request from multiple 
imports).


Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Integrating the Webs' dependency systems

[Juan Ignacio Dopazo]

On Tuesday, May 27, 2014 8:51 PM, Ian Hickson i...@hixie.ch wrote:


Is there a description of what the non-ES spec should say? That is, what 
is the interface that System exposes that needs to be implemented by 
this non-ES spec? What are the spec hooks that this non-ES spec would need 
to invoke?
The W3C System would have to provide the following hooks in a way that matches 
what the web platform is supposed to do:
* normalize hook: take a module ID string (like from import 'some-id' 
and normalize it to a unique ID through out the system
* locate hook: based on the module ID, locate the asset to be fetched 
somehow (find its URL)
* fetch hook: make the necessary network request
* translate hook: probably not something the web platform will care 
about for now since its intended to translate other languages into EcmaScript
* instantiate hook: if the fetched source is an ES6 module, then 
everything is covered. But if it's any other asset or a dynamic module (read 
AMD or similar) the instantiate hook is in charge of creating the necessary 
Module instance. For example, it would deal with things like importing CSS 
files by returning an empty module.
Ah so the ES6 import statement can import anything, even things that 
aren't ES6 modules?


It would certainly be cool if that was possible.
It could. You can avoid importing anything into the ES scope by doing `import 
foo`without specifying what exactly you would be importing. Based on that, 
you could implement the previous hooks so that the fetch hook knows how to 
fetch assets other than scripts and the instantiate hook knows how to insert 
the asset into the page.

 I believe that such an extension of the ES6 Loader has a chance to 
 provide value to the community. I guess it won't solve all problems ;-)


Would this be a replacement to the aforementioned System?
It would probably be an extension to System or any other ES Loader instance. 
See https://github.com/systemjs/systemjs for an example.

  
Given all this and the previously mentioned module tag, script needs= 
probably doesn't make much sense, does it?


Juan Dopazo___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Loader and Module as globals?

[Juan Ignacio Dopazo]

The latest draft doesn't seem to specify (or I can't find) where the Loader and 
Module constructor object will be accessible from. Will they be available as 
properties of the global object, as properties of System or as properties of 
Reflect?

Thank you,
 
- Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Final iterator spec

[Juan Ignacio Dopazo]

On Thursday, February 20, 2014 9:27 AM, joe joe...@gmail.com wrote:

Thanks.  Btw, where is the final spec stored?

You can find it in the Drafts page: 
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts.
 
 harmony:specification_drafts [ES Wiki]Draft Specification for ES.next 
(Ecma-262 Edition 6) This page contains a historical record of working draft of 
the ES.next specification prepared by...
View on wiki.ecmascript.org   

And there is an HTML version here: 
http://people.mozilla.org/~jorendorff/es6-draft.html
 
- Juan___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Import Expressions

[Juan Ignacio Dopazo]

On Friday, January 31, 2014 8:10 PM, Calvin Metcalf calvin.metc...@gmail.com 
wrote:

what I'm talking about would be sugar for something functionally equivalent to:
```js
import 'bar' as ___temp1;
import 'baz' as ___temp2;
var foo = Math.random()  0.5 ? ___temp1 :___temp2;
```


I think it's good that imports are not expressions. It makes it a lot easier to 
analyze them statically.

These use cases are probably better solved at the Loader level. If I understood 
the spec correctly, If you have modules that you want to load conditionally you 
can set up a `normalize` hook that changes which module is actually loaded.

System.normalize = function (name) {
  if (name === 'bar'  Math.random()  0.5') {
    return 'baz'
  }
  return name;
};

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise.cast and Promise.resolve

[Juan Ignacio Dopazo]

On Tuesday, January 28, 2014 10:13 AM, Kevin Smith zenpars...@gmail.com wrote:


My take is that the difference between cast and resolve is so
subtle that I don't think it captures developer intention. In
other words, if I see some code calling Promise.cast(otherPromise),
I can't be sure that the developer made an intentional choice over
Promise.resolve(otherPromise).


Note that `Promise.resolve(p)`, where p is a promise, does *not* return an 
eventual for the eventual value of p.  Rather, it returns an eventual for p, 
literally.  Promises should be considered fully parametric (in other words, 
nestable).

That's not true as per the last consensus. There was `Promise.fulfill(p)` which 
would've nested promises, but it was left for ES7 to investigate 
fulfill+flatMap.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Specifics of `class` and `super`

[Juan Ignacio Dopazo]

On Mon, Dec 9, 2013 at 2:36 PM, Till Schneidereit t...@tillschneidereit.net 
wrote:

You could also check the output of Traceur and TypeScript. I don't know how 
close either of them are to implementing the exact semantics of ES6 classes, 
but I'm sure it'll be helpful in any case.




Yup. See 
http://www.typescriptlang.org/Playground/#src=class%20Person%20%7B%0A%09private%20name%3A%20string%3B%0A%09%0A%09constructor(name)%20%7B%0A%09%09this.name%20%3D%20name%3B%0A%09%7D%0A%09%0A%09say(message%3A%20string)%20%7B%0A%09%09return%20this.name%20%2B%20'%20says%3A%20'%20%2B%20message%3B%0A%09%7D%0A%7D%0A%0Aclass%20Pirate%20extends%20Person%20%7B%0A%09constructor(name)%20%7B%0A%09%09super('Captn%5C'%20'%20%2B%20name)%3B%0A%09%7D%0A%09%0A%09say(message)%20%7B%0A%09%09return%20super.say(message%20%2B%20'%20Arrr!')%3B%0A%09%7D%0A%7D

 - Juan



On Monday, December 9, 2013 2:37 PM, Till Schneidereit 
t...@tillschneidereit.net wrote:
 
You could also check the output of Traceur and TypeScript. I don't know how 
close either of them are to implementing the exact semantics of ES6 classes, 
but I'm sure it'll be helpful in any case.




On Mon, Dec 9, 2013 at 6:28 PM, James Long longs...@gmail.com wrote:

I read Allen's email wrong, thought it implied `this` was lexically
scoped (which I know is not true. very little sleep at an airport...).

I'll keep digging through the spec, but if someone has a quick example
what ES5 code I could compile to for roughly the same semantics, that
would be helpful. From what I understand, you're saying that `super`
is lexically scoped to the `class` that is defined so I can statically
compile it out to something like `Foo.prototype.method` if `Foo` is
the parent class. Anyway, no need to trail on about this, I should
just RTFS.

- James


On Mon, Dec 9, 2013 at 11:23 AM, Brendan Eich bren...@mozilla.com wrote:
 OnMon, Dec 9, 2013  at 10:22 AM,  Allen Wirfs-Brock

 al...@wirfs-brock.com  wrote:

   super is lexically scoped


 This is true.



 James Long wrote:

 So essentially super is an alias for `Object.getPrototypeOf(this)` ?


 But |this| is not lexically scoped, so your question's answer must be no.

 /be
___
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___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: AP2 makes laziness easy.

[Juan Ignacio Dopazo]

On Mon, Aug 26, 2013 at 12:54 PM, Mark S. Miller erig...@google.com wrote:

 Since today this code will still typically work, and will in the near
 future successfully become lazier, we should expect a lot of such code to
 exist by the time we roll out our new standard. This brings us back to our
 need to chose between compat-duck, where thenable is simply (typeof
 obj.then === 'function'), and narrow-duck, where some additional marking
 is required.

 (...)


 IMO, I expect it is already too late for narrow-duck, and that we will
 find we are already stuck needing to standardize compat-duck, even though
 it will misinterpret some other existing non-thenable uses of then.

 I don't believe it's unthinkable to ask the community to update their
implementations to match the spec either way. I see two reasonable options:

- Instead of full compat-duck, add another method to the spec and duck
check both. It can be flatMap() or done() if there's interest in either
- Use some sort of brand check that is easy to implement and hard to match
by mistake

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: setImmediate

[Juan Ignacio Dopazo]

2013/8/8 David Bruant bruan...@gmail.com


 2) A way to run a function after the current microtask and before
 yielding back to the browser, same as what Object.observe() does. This is
 what we need for promises and other library features that depend on some
 level of asynchronicity and deal with data. We want to work on our data
 before the browser renders again.

 I'm having a hard time understanding before the browser renders again.
 I'm afraid this is a asking for laggy UIs if there is the least bug. I
 would rather recommend the following approach: play with abstract data
 (regular objects/arrays, etc.) in tasks/microtasks and update UI (DOM,
 Canvas, SVG, etc.) in requestAnimationFrame callbacks.


That's precisely what we want to do and why we need a mechanism for
scheduling code to run in the next task/microtask.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises Consensus

[Juan Ignacio Dopazo]

If then() deep flattens, flatMap() only flattens one level and promises
assimilate thenables, is branding really necessary?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promises Consensus

[Juan Ignacio Dopazo]

Does this all mean that you're ok with having promises-for-promises?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Unique Public Symbols as Strings

[Juan Ignacio Dopazo]

2013/7/29 Brandon Benvie bben...@mozilla.com

 My experience is that inheritance is usually done shallowly and these
 collisions are rare and obvious when they happen.

 It is not obvious when using mixins in UI code. Method names like
_onWindowResize are common and can easily lead to conflicts.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Do modules make static unnecessary?

[Juan Ignacio Dopazo]

static properties of constructors have been used in JS mostly for
transport and avoiding pollution of the global object. For example
DOMPromise has Promise.any(), a static method. But if there were modules,
any() would probably be better suited as an export: import {Promise, any}
from @promise.

So, in the light of modules, are static methods necessary?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: [[Invoke]] vs [[Get]]

[Juan Ignacio Dopazo]

2013/6/9 Brian Di Palma off...@gmail.com

 On Sun, Jun 9, 2013 at 4:18 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
 
  No, we can't just blindly call GetValue in step 1 as that would lead to
 the
  get trap being invoked on a proxy (which is the wrong trap).
 

 Why can't we have the two traps trigger?

 I would imagine that proxies are meant to be consistent with
 getters/setters?


It seems like the right reasoning. The result of these operations should be
equivalent:

obj.f();

let f = obj.f;
f.call(obj);

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

State of generators?

[Juan Ignacio Dopazo]

Hello,

I'm having trouble understanding the current status of generators. Last
time I checked, the standard was what V8 has just implemented:

- Generator objects had next(), send(), throw() and close() methods
- These methods returned objects with value and done properties

It seems now that:
- send() and close() are gone
- next(value) seems to be the same as send(value)
- All methods seem to return the yielded result, not an object with a
value property

So, is StopIteration back? How do we know if a generator is done?

Thanks,
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: State of generators?

[Juan Ignacio Dopazo]

2013/6/8 Allen Wirfs-Brock al...@wirfs-brock.com


 On Jun 8, 2013, at 1:42 PM, Juan Ignacio Dopazo wrote:


  - All methods seem to return the yielded result, not an object with a
 value property

 No, yield produces a nextResult object.  The last line of the yield
 runtime semantics in 13.4.1.2 is:
  Return the result of GeneratorYield(CreateItrResultObject(value,
 false)).

 Note that a iteration result object is being created and passed to the
 abstract operation at does the actual context switch.

 
  So, is StopIteration back? How do we know if a generator is done?

 No.  via a object that implements the ItrResult (name subject to change)
 interface as specified in 15.19.1.3

 I totally missed the CreateItrResultObject part. Thank you very much!

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Module syntax

[Juan Ignacio Dopazo]

Now that it's been decided that braces are not a form of destructuring and
the colon replaced with `as`, what's the benefit of using braces? Why not
this previous proposal?

import foo as foofoo from foo;

import bar as bar;

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Future cancellation

[Juan Ignacio Dopazo]

2013/5/1 Anne van Kesteren ann...@annevk.nl

 On Wed, May 1, 2013 at 10:45 AM, Alex Russell slightly...@google.com
 wrote:
  This is what I've sketched in various places, including for Anne WRT
 XHR. I
  suppose (without any cause) that folks would pick up on the idea that the
  minimal Future superclass was being explicitly designed to be
 subclassable
  to address issues like this and progress notification. Perhaps we need to
  call it out more explicitly in the spec?

 The specification does need to address that better, in particular what
 then() and catch() might return for subclassed futures. We found use
 cases both for returning a new instance of the subclassed future
 itself (ProgressFuture) and simply returning a new base future (for
 the crypto APIs).


For YUI we tried something like:

then(callback, errback) {
  return new this.constructor(function (resolver) {
// ...
  });
}

While it is true that there are use cases for both, there are use cases
that get broken when returning a instance of the subclass. For example, a
LazyPromise which runs the initialization function only when then() is
called, breaks down with this approach. It seems to me that if some use
cases break and for others the same effect can be achieved using a
different approach, then the safest path should be taken. That seems to be
only returning base promises from then().

2013/5/1 Kevin Smith zenpars...@gmail.com


 I think this difficulty points to a deeper issue with attempting to make a
 promise something other than a placeholder for a value.


The fact is that in a way promises are already a representation for a value
and for an operation. What is a promise for undefined? Let's say I have a
database object with a close() method that works asyncronously. If close()
returns a promise, which value does it represent?


As for cancellation, I worry about the ergonomics of returning { promise,
cancel } pairs. Like Alex mentioned, a subclass makes a lot more sense for
XMLHttpRequest. And if it works for XHR why shouldn't it work for other
promises?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Future cancellation

[Juan Ignacio Dopazo]

2013/4/30 Alex Russell slightly...@google.com

 First, synchronous resolution needs some justification. I don't understand
 why you've added it in the first design.


When I first read about the synchronous resolution flag I thought it made
sense, for example in the context of network requests. When a network
request is completed you can call resolve() with the synchronous flag
because you know you're in a new tick of the event loop. It basically
allows you to avoid scheduling notification in the future when you already
know you're being asynchronous.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Promise/Future: asynchrony in 'then'

[Juan Ignacio Dopazo]

2013/4/30 Claus Reinke claus.rei...@talk21.com

 I have not yet been able to decide whether DOMFuture has a
 similar provision, or how this note is meant to be interpreted.


I think it is covered by this language in the accept() algorithm:

 Otherwise, the synchronous flag is unset, *queue a task* to process
future's resolve callbacks with value

queue a task points to text in the Web Apps spec regarding the event loop.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A Challenge Problem for Promise Designers (was: Re: Futures)

[Juan Ignacio Dopazo]

2013/4/26 Kevin Smith zenpars...@gmail.com

 What exactly is the controversy here?

 I think we all agree with the semantics of then as specified in
 Promises/A+.  (If not, then we have a really big problem!)


Promise/A+ does not prohibit promises for promises. But in practice the
problem is recognizing what is a promise. There are two options:

1) Recognize all thenables as promises
2) Recognize only the promises from your own library

Many implementations go with (1), including ODMFuture. Since it doesn't
distinguish between promises and thenables, then() flattens all of them.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Juan Ignacio Dopazo]

2013/4/26 Tab Atkins Jr. jackalm...@gmail.com

 On Fri, Apr 26, 2013 at 11:25 AM, Kevin Smith zenpars...@gmail.com
 wrote:
  Actually, I may have gotten it terribly wrong (apologies).  In my
 prototype
  implementation, the following:
 
  Future.accept(Future.resolve(1)).then(value = {
 
  console.log(value !== 1);
  return Future.accept(Future.resolve(1));
 
  }).then(value = {
 
  console.log(value === 1);
  });
 
  logs
 
  - true
  - true
 
  Is that what it should be doing, according to the DOM spec?  Anne, Alex?

 No, it should be true, then false.

 I think Kevin's assertion is correct. According to the spec, callbacks are
wrapped in something called a future wrapper callback. When a promise is
returned from the callback, the wrapper does this:

Let value be the result of invoking callback with argument as argument.
 (...) run resolver's *resolve *with value and the synchronous flag set.


*resolve* tries to adopt the promise by being recursive, effectively
flattening the promise:


- If value is a JavaScript Object, set then to the result of calling
the JavaScript [[Get]] internal method of value with property name then.
- If JavaScript IsCallable(then) is true *[treats all thenables the
same way]*, run these substeps and then terminate these steps:
- Call the JavaScript [[Call]] internal method of then with this value
value and *resolve *and *reject *as arguments.

 If resolved called the thenable's then() with *accept *and reject, it
would only unwrap one layer.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Juan Ignacio Dopazo]

2013/4/26 Anne van Kesteren ann...@annevk.nl

  If resolve called the thenable's then() with accept and reject, it would

  only unwrap one layer.

 Oops yeah. I guess that should be fixed. :/


Fixing that would break compatibility with Promises/A+. To remain
compatible with A+ and unwrap only one layer, the spec would need a way to
discern promises from thenables.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: What Are We Arguing About? (was: Re: A Challenge Problem for Promise Designers)

[Juan Ignacio Dopazo]

2013/4/26 Mark Miller erig...@gmail.com

 On Fri, Apr 26, 2013 at 8:18 AM, Andreas Rossberg rossb...@google.com
  wrote:
 [...]


  the term future

 What  are the chances of the WHATWG renaming the spec to DOMPromise?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Juan Ignacio Dopazo]

2013/4/26 Kevin Smith zenpars...@gmail.com


  Oops yeah. I guess that should be fixed. :/


 Fixing that would break compatibility with Promises/A+. To remain
 compatible with A+ and unwrap only one layer, the spec would need a way to
 discern promises from thenables.


 I don't think so.  It has no bearing on Promises/A+, because A+ doesn't
 test the case where the promise's value is itself a promise.


Yes, sorry. It will on version 1.1:
https://github.com/promises-aplus/promises-spec/#the-promise-resolution-procedure

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Futures

[Juan Ignacio Dopazo]

2013/4/23 Ron Buckton rbuck...@chronicles.org

 I fall mostly under the native futures should not implicitly chain
 library futures camp. Its easy enough to write:

 var p = // some thenable
 return new Future(resolver = p.then(resolver.resolve, resolver.reject);


That looks terrible inefficient, so in our implementation we tried to make
chaining easier by returning a new promise from then() based on
promise.constructor. And once in the wild the issues started appearing like
someone trying to implement a LazyPromise and having issues chaining
then(). So we're considering reverting to returning a simple promise before
it becomes technical debt.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Weak event listener

[Juan Ignacio Dopazo]

2013/3/25 Erik Arvidsson erik.arvids...@gmail.com

 WeakMap would not work in this specific case since a WeakMap cannot be
 iteratered.


I thought there was an iterable WeakSet for ES6. Was it postponed to ES7 or
just dropped?

Thanks,
Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: On Scope And Prototype Security

[Juan Ignacio Dopazo]

2013/3/19 Andrea Giammarchi andrea.giammar...@gmail.com


 @Juan I don't want the complexity of a Proxy, I want objects that inherit
 from my private object so that what changes in my private object reflects
 automatically everywhere.


Maybe you're misunderstanding my example. I'm not returning a proxy each
time, I'm using a proxy as the prototype of all your instances. That way
even though the prototype is accesible with Object.getPrototypeOf(outer),
the untrusted party still can't do anything with it. And you can still
modify your private object and the change is reflected everywhere.

If you did understand it, then what are we missing?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: 10 biggest JS pitfalls

[Juan Ignacio Dopazo]

I'm surprised not to see Automatic Semicolon Insertion in the list.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Preventing instance extension

[Juan Ignacio Dopazo]

 On Fri, Nov 11, 2011 at 4:23 PM, Xavier MONTILLET xavierm02@gmail.com
  wrote:

Object.getPrototypeOf(this) === Point.prototype = this instanceof Point

 Actually, no. this instanceof Point = Object.getPrototypeOf(this) ===
Point.prototype, but not the other way around.


 And I don't understand your problem _ 

 The problem is this that when you do prototypical inheritance using
constructors you usually call the superclass before any of the subclass
constructor code. So if you just seal(this) in the constructor of the
superclass the subclass can't add properties to the object.

function Person(name) {
  this.name = name;
  Object.seal(this);
  console.log(this instanceof Person, Object.getPrototypeOf(this) ===
Person.prototype); // true false when doing new Pirate()
}

function Pirate() {
  Person.apply(this, arguments);
  this.eyepatch = true;
}
Pirate.prototype = Object.create(Person.prototype);

var captain = new Pirate('Blackbeard');
console.log(captain.eyepatch); // undefined


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: More thoughts on Allen’s class definition pattern

[Juan Ignacio Dopazo]

On Sun, Oct 30, 2011 at 10:13 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:

 I kind of like the rationale of: You (JS users)  asked for classes *but
 they really don't fit very well with the core concepts of the language*we 
 have to build upon.
 Allen


Why? We have seen in more than one occasion how they do fit well.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Terminology: types, constructors, classes, …

[Juan Ignacio Dopazo]

On Sun, Oct 23, 2011 at 3:07 AM, Axel Rauschmayer a...@rauschma.de wrote:

 - What do you call something that produces instances in JavaScript? A
 class? A type? A constructor? Or is a constructor the implementation of a
 type?


At least in my part of the everyday life of a JavaScript programmer, we call
functions that we invoke with new mostly classes and sometimes
constructors. In contrast, values not objects are the ones that have types
(only boolean, number and string) even if values in JS are indeed objects.



 - If instance factory B inherits from instance factory A, is B a subclass
 of A? B a subtype of A? B a subconstructor of A?


We say it's a subclass, but we mostly say inherits from.


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Grawlix

[Juan Ignacio Dopazo]

On Thu, Oct 13, 2011 at 6:32 AM, Joe Developer joe.d.develo...@gmail.comwrote:

 Truthfully the - arrow construct is one that I have an aversion to which
 borders ( I'll admit ) on the irrational


My emails where private on purpose because all those arguments where made
before. Just look through the archives.

I also answered privately because I did not want to bring up arrow functions
in a thread named Grawlix. I don't think they qualify. | is very much
arbitrarily chosen to look a little like an UMD inheritance arrow. - by
contrast looks very similar to what everyone is (hopefully) taught in school
when learning about functions in math, even non programmers. | would be
mostly used by abstraction makers. - by abstraction users.


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Harmony transpilers

[Juan Ignacio Dopazo]

Hi! Is there anyone working on a Harmony transpiler besides Traceur? It'd
be really useful to have a transpiler that justs desugars (what's possible
to desugar) without using a library like Closure, the way CoffeeScript is
working nowadays.

Thanks,


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Harmony transpilers

[Juan Ignacio Dopazo]

On Tue, Oct 11, 2011 at 12:42 PM, John J Barton johnjbar...@johnjbarton.com
 wrote:



 On Tue, Oct 11, 2011 at 6:41 AM, Juan Ignacio Dopazo 
 dopazo.j...@gmail.com wrote:

 Hi! Is there anyone working on a Harmony transpiler besides Traceur?


 I'd like to understand why Traceur is not suitable. As far as I understand
 it was written to study new directions in JS.

 Traceur is very good! I'd just like to have something that compiles to ES5
without intermediate libraries, the way CoffeeScript works, so that it's
easier to debug and use in NodeJS.

Traceur does this very well for certain features, like arrow functions and
the rest operator. But classes still use library code and aren't very human
readable. See:

class Person {
  constructor(name) {
this.name = name;
  }
}

... is compiled to:

var Person = traceur.runtime.createClass(Person, null, null,
function(name) {
  this.name = name;
}, undefined, { }, function $static() { }, null);

Compare it to CoffeeScript:

class Person
  constructor: (name) -
this.name = name
  sayHi: - 'Hi!'

Coffee to JS:

var Person;
Person = (function() {
  function Person(name) {
this.name = name;
  }
  Person.prototype.sayHi = function() {
return 'Hi!';
  };
  return Person;
})();


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Harmony transpilers

[Juan Ignacio Dopazo]

Thanks for all the answers!

On Tue, Oct 11, 2011 at 3:40 PM, John J Barton johnjbar...@johnjbarton.com
 wrote:

 I was trying to encourage Jake and Juan to participate in taking it
 forward.


I'd love to, but I'm afraid my interpreter-writing skills are somewhat null
if not undefined. I'm interested in language design and interpreting but I'm
barely scratching the surface with SICP for now.

On Tue, Oct 11, 2011 at 5:40 PM, Erik Arvidsson erik.arvids...@gmail.com
 wrote:

 We should make it optional to include the
 required runtime functions in the generated code at least.

 Thanks! That would be very useful for targeting Node.

On Tue, Oct 11, 2011 at 6:29 PM, Kam Kasravi kamkasr...@yahoo.com wrote:

 I've implemented several harmony proposals in es.next by expanding the
 grammar in pegjs (
 https://github.com/dmajda/pegjs/blob/master/examples/javascript.pegjs).
 (..) I like my approach because the grammar is easy to extend and I don't
 know of any other transpiler whose ast/generators are in the target
 language.

 pegjs looks great! I'm playing with the online version right now. I already
have a parser that interpretes ^ as Math.pow() *happy newbie*

On Tue, Oct 11, 2011 at 10:17 PM, David Herman dher...@mozilla.com wrote:

  Traceur is very good! I'd just like to have something that compiles to
 ES5 without intermediate libraries, the way CoffeeScript works, so that it's
 easier to debug and use in NodeJS.

 You aren't going to be able to match CoffeeScript's readability for many
 features, especially generators, private names, and proxies. Those require
 deep, whole-program compilation strategies.

 Dave

 I understand that. However proxies are already in V8 and SpiderMonkey.
WeakMaps are in SpiderMonkey as well. I'm already looking at using proxies
in NodeJS to rewrite a MongoDB driver. So what I'm looking for is to try out
all the syntax that's just sugar (classes, destructuring, rest, spread, etc)
to see how it changes my everyday coding in my small projects that have room
for experimentation.


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: traits feedback

[Juan Ignacio Dopazo]

On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten rayn...@gmail.com wrote:

 Object.create does indeed require  propertydescriptors as the second
 argument. This is the easiest way to send meta-data like read-only.

 However it's verbose and the defaults are restrictive. I've written a small
 library (github.com/Raynos/pd) to make it less verbose, you might find it
 useful.


 That's what 
 Object.getOwnPropertyDescriptorshttp://wiki.ecmascript.org/doku.php?id=strawman:extended_object_api
  would
be for. I don't know why it hasn't gotten into Harmony yet.


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: On I got 99 problems and JavaScript syntax ain't one

[Juan Ignacio Dopazo]

On Thu, Oct 6, 2011 at 12:01 AM, Quildreen Motta quildr...@gmail.comwrote:

 On 05/10/11 23:06, Brendan Eich wrote:

 On Oct 5, 2011, at 7:01 PM, Quildreen Motta wrote:

  On 05/10/11 22:05, Brendan Eich wrote:

 On Oct 4, 2011, at 7:19 AM, Juan Ignacio Dopazo wrote:

 - A sane way of dealing with equality, identity and basically a lot of
 what's in http://wtfjs.com/

 Some of that is due to implicit conversions, not any equality-ish
 operator.

 I really never understood people's complaints about equality comparisons
 in JavaScript. There are only two operators, with clear and well defined
 semantics/use-cases:

 `==' (Abstract equality) is used for comparing the value of two objects,
 without taking data-structure into account.

 This operator is insane due to implicit conversions it does when operand
 types are not the same. In such cases it is not an equivalence relation.


Yes, == and === work fine. The problem is not in how they work, but in the
learning curve for new users of the language. I think most expect == to work
as ===. That, combined with object wrappers for values (new Number(5), new
Boolean(false), etc), seems to be an endless source of confusion for
beginners.

Of course pretty much every operator does type coercion, so tampering with
== and === could be as much detrimental as constructive.


Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: On I got 99 problems and JavaScript syntax ain't one (was: OnIncremental Updates)

[Juan Ignacio Dopazo]

Yes, tools should be better, but they need to start becoming better by
themselves as previous discussions here have noted.

However, there are problems in the language that need to be addressed by
both syntax and APIs. We need:

- A sane way of dealing with equality, identity and basically a lot of
what's in http://wtfjs.com/
- Ways of isolating code from the global scope
- Tools for avoiding XSS

And there are many other features that would help a lot.

There was talk about an is or eq operator to fix equality, but it seems
it got demoted or interest was lost. I'd love to hear more about what
ES.next will do about ==, === and value wrappers like new Boolean(false).
Replacing == with ~= and === with == crossed my mind once.
Modules from ES.next and the sandbox attribute for iframes in HTML5 cover
pretty much everything we need for avoiding the problems of the global
scope.
Quasis should help with XSS, but as as Nicholas Zakas
saidhttp://www.nczonline.net/blog/2011/10/03/when-web-standards-fail-us/,
an API String.htmlEscape() would be implemented faster and contribute more
in the short run.

So we need syntax as much as we need new APIs.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: {Weak|}{Map|Set}

[Juan Ignacio Dopazo]

On Wednesday, September 14, 2011, David Bruant david.bru...@labri.fr
wrote:
 Also, I would like to talk a little bit about terminology. WeakMaps have
 their name inspired by the idea of weak references which have
 particular garbage-collection properties. From the developer
 perspective, this seems to be some sort of implementation detail they
 should not be aware of.
 As far as I know, current functions/constructors have their name
 inspired by the contract they fulfill rather than implementation
 considerations. The difference between current WeakMaps and Maps is
 their contract. In the latter, keys can be enumerated, in the former
 not. I think that this is the difference that should inspire different
 names rather than the implementation optimisation that is induced by
 this contract difference.


In the last few days I had to write a piece of code that would strongly
benefit from WeakMaps. I needed to store information about DOM nodes and
retrieve it later, and these nodes aren't in my control so they can be
detached at any time by someone else. If the references I kept were weak,
I'd be sure that I wouldn't be causing a memory leak. And that's important
in this case because the nodes are very likely Flash objects which can
easily mean 20-50mb in memory. So knowing that a reference is weak is
important information.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: IDE support?

[Juan Ignacio Dopazo]

On Mon, Sep 12, 2011 at 5:17 PM, Axel Rauschmayer a...@rauschma.de wrote:

 Regarding tool support, adding type annotations in comments (JSDoc-style)
 should be enough, mid-term.

 For IDEs, it would really help if there weren’t so many competing standards
 for even the most basic things in the JS world.  For example:

 (1) Doc comments
 (2) Unit tests
 (3) Type annotations
 [ Will become language features: inheritance API, module API ]

 Is there really no way to standardize these? Some kind of best practice,
 recommended by TC39? The current state of affairs really hurts JavaScript.
 If Java can standardize (1) and have the quasi-standard JUnit für (2), why
 can’t JavaScript?

 --
 Dr. Axel Rauschmayer

 CommonJS is a great place to start. http://www.commonjs.org/

They're already standardizing Promises and Asynchronous Module Loaders. They
have also started with Unit Tests. And the great part is that the community
is actually listening and taking it into account. Dojo 2 will use CommonJS
modules and I wouldn't be surprised if jQueryUI went that way (I already
have a draft implementation for it).

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Harmony - proxies | asynchronous

[Juan Ignacio Dopazo]

There is already a Node module that uses Proxies as a way of enforcing
promises:

https://github.com/sam-mccall/node-plate

It allows your to write:

var pfs = plate(fs);
pfs.writeFile('/etc/passwd.bak', pfs.readFile('/etc/passwd'));
pfs.end(function(err) { if(err) throw err; console.log(It's saved); });

Juan

On Fri, Sep 2, 2011 at 12:02 PM, Xavier MONTILLET
xavierm02@gmail.comwrote:

 Hi,

 I'm just a lambda JavaScript programmer who loves building black boxes
 with the smallest APIs possible and a couple of hours ago, I found out
 Proxys existed and since then, I've been watching talks and reading
 articles about them. And it sure looks awesome.

 But there's one thing I didn't get:
 Will we be able to use them to provide an API for remote objects?

 Because it looks it it can but it lacks the asynchronous aspect.
 This guys says it will:

 http://code.google.com/p/es-lab/wiki/Talks#Changes_to_ECMAScript,_Part_2:_Harmony_Highlights_-_proxies_and
 But when I look at the draf (

 http://wiki.ecmascript.org/doku.php?id=harmony:proxies#an_eventual_reference_proxy
 ), the only sentence I see asynchronous in is this one:
 This example shows how to implement a proxy that represents an
 eventual reference, enforcing asynchronous property access on an
 object.

 And in the code below, the only thing that might do something
 asynchronous is this:

 get: function(receiver, name) {
 return promiseFor(function(){return obj[name];});
   },

 And it sounds more like it returns some value and *then* gets the real one.
 And this promiseFor function appears nowhere else on the page...

 And if it can not be asynchronous, it (probably) can't be used in
 Node.JS which, apart from the browser, will more likely become one of
 the most used JavaScript environment.
 But the thing is that if you provide both a synchronous and an
 asynchronous APIs, it might become a big mess...
 The the best solution seems to be to provide only an asynchronous API
 with a callback given as argument to get, set, has, hasOwn and so on.

 But then is gets quite strange because you do:

 var value = proxy.property;

 and it does

 var value = handler.get( proxy, 'property' );

 but if get is asynchronous this can not work...
 Or then it has to be some strange C++ code and we loose all the
 interest of having asynchronous requests in the first place.

 Thank you in advance for your potential future response.

 

 To put it in a nutshell: Will Proxys support asynchronous requests?

 

 If my question is dumb and / or pointless, I'm sorry for wasting your time.
 ___
 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: July TC39 meeting notes, day 1

[Juan Ignacio Dopazo]

On Thu, Jul 28, 2011 at 1:21 AM, Brendan Eich bren...@mozilla.com wrote:

 Math functions

...


Can I add a request? Math.randomInt(n) returning [0, n) would be a nice
addition. Additionally but not necessarily, it could accept an optional
extra parameter for Math.randomInt(from, to). Most of the time, when writing
games or simple applications a random integer is a lot more useful than a
float.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Public/private namespaces in harmony classes proposal

[Juan Ignacio Dopazo]

On Fri, Jul 8, 2011 at 3:15 AM, Brendan Eich bren...@mozilla.com wrote:

 On Jul 7, 2011, at 11:07 PM, Gavin Barraclough wrote:

  Ah, I see.  It's a fair point, but isn't this already a hazard that the
 language faces?

 Not with private names.

 There's also something that was probably discussed but never got to this
list:

Private instance properties were considered to be accessible by all
instances of the class. That's a new concept in ES. Were there arguments for
keeping instance private properties private to the instance?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Public/private namespaces in harmony classes proposal

[Juan Ignacio Dopazo]

On Fri, Jul 8, 2011 at 12:15 PM, Brendan Eich bren...@mozilla.com wrote:

 On Jul 8, 2011, at 7:43 AM, Juan Ignacio Dopazo wrote:

 My first thought was: why not just statically replace this.x, with private
 x, with this[xPrivateName] and forget about accessing private properties
 of other objects? That would still leave the problem of closures inside
 methods, though...


 If xPrivateName is a private name object, then there's no reason to forget
 about accessing private properties of other objects. Both
 this[xPrivateName] and other[xPrivateName] work as you would expect.

 /be

You are very much right. What are the open issues with privates in classes
then?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Public/private namespaces in harmony classes proposal

[Juan Ignacio Dopazo]

On Fri, Jul 8, 2011 at 1:52 PM, Brendan Eich bren...@mozilla.com wrote:

 On Jul 8, 2011, at 8:45 AM, Juan Ignacio Dopazo wrote:

 You are very much right. What are the open issues with privates in classes
 then?


 The wiki lists some. Here are a few from memory:

 * Syntax to use instead of private(this), private(other). The straw
 private(foo) syntax is too verbose and it wrongly suggests that a private
 data record is a distinct object. Are we ready to claim @ as prefix and
 infix operator (with restriction against LineTerminator on its left)?


Why do privates need special syntax? Isn't the point to just use them with
this.privateWhatever?


 * Private prototype methods and other properties may be useful, especially
 methods. One can wrap a closure around the class and put private helpers
 there, of course, but with private syntax in the proposal, why stop short?


+1!


 If we do support private prototype properties, then what are the semantics?
 Private name objects, as recently noted, have their .public counterparts
 passed as name parameters to proxy traps, so something about private
 prototype properties may be observable:

 class Victim prototypes Proxy { private protoMethod() {
 privat(super).protoMethod(); } }


Isn't that only an issue of protected vs private?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Making super work outside a literal?

[Juan Ignacio Dopazo]

On Wed, Jun 22, 2011 at 1:01 PM, Sean Eagan seaneag...@gmail.com wrote:

 Its value is already resolved via prototype climbing,  I don't see the
 tremendous cost is simply making this value accessible within the
 function activation which occurs as a result of the prototype
 climbing.


Can the value of a dynamic super be unambiguously resolved with prototype
climbing and without an extra implicit parameter?

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Making super work outside a literal?

[Juan Ignacio Dopazo]

On Wed, Jun 22, 2011 at 3:01 PM, Sean Eagan seaneag...@gmail.com wrote:

 On Wed, Jun 22, 2011 at 12:07 PM, Juan Ignacio Dopazo
 dopazo.j...@gmail.com wrote:
  Can the value of a dynamic super be unambiguously resolved with prototype
  climbing and without an extra implicit parameter?

 Yes, it can be unambiguously determined by prototype climbing, the
 only information from the call site that is used is the base ( |this|
 ) value of the method call or accessor property access, whose
 prototype chain is the one that is climbed.

 Cheers,
 Sean Eagan


If I understood correctly this thread, the problem seems to be in
distinguishing between |this| and the prototype that owns the function.
Let me see if I can explain it...

var A = {
  method: function () { /* do something */ }
};

var B = Object.create(A);
B.method = function () {
  Object.getPrototypeOf(this).method(); // if you do this, then in the
context of A.method |this| will be A, not B
  Object.getPrototypeOf(this).method.call(this); // if you do this, then
it's all ok unless you want add another level
};

var C = Object.create(B);
C.method = function () {
  Object.getPrototypeOf(this).method.call(this); // Now in B.method |this|
will be C and getPrototypeOf will be used with C... an infinite loop
};

IIRC, this is why a |here| value is needed.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Classes: suggestions for improvement

[Juan Ignacio Dopazo]

On Mon, Jun 13, 2011 at 12:01 PM, Kam Kasravi kamkasr...@yahoo.com wrote:


 On Jun 13, 2011, at 1:55 AM, Axel Rauschmayer a...@rauschma.de wrote:

 Indeed a number of frameworks use 'initialize' for their 'ctor'. I imagine
 this has been
 heavily discussed within TC39, but perhaps some of the rational has not
 made es-discuss.

 It was posted somewhere... The rationale is that 'constructor' is already a
property of the prototype that points to the constructor function.

function Test() {}
(Test.prototype.constructor === Test) // true

It was chosen to replace 'new' because o.new() is correct under ES5.

 On Sun, Jun 12, 2011 at 10:17 PM, Brendan Eich bren...@mozilla.com wrote:


 I'm not sure classes should grow to have private class or prototype
 variables in ES.next. Mark stripped things down to help get classes in. The
 one reason I come back to them: private methods for common subroutining are
 frequent in practice. So YAGNI doesn't work. One can always closure- or
 module-wrap by hand; that's the counterargument.

 /be

 I'm not sure that's a counterargument. The whole point of the classes
proposal is to simplify the use of a common pattern. Private methods for
subroutines are a very common use case.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Harmony:classes static and private

[Juan Ignacio Dopazo]

On Wed, Jun 8, 2011 at 3:13 PM, Bob Nystrom rnyst...@google.com wrote:

 That's better, but public and private are still less than ideal
 keywords here since Javascript's use of them is distinctly different from
 other languages. Alas, they were the best we could come up with.


public confuses me because its name is related to access control. And
because the following doesn't make any sense and I expected to be able to
declare a private instance property:

*class *Monster {
*private public* health = 10;
}

So, taking a page from CoffeeScript's for own ... in extension, what do you
think about this?

*class *Monster {

*private own* health = 10;

*private static *allMonsters = [];

*own *id;

constructor() {
*this*.id = Monster.allMonsters.length;
Monster.allMonsters[this.id] = this;
}

}

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Thoughts on WeakMaps

[Juan Ignacio Dopazo]

On Tue, Jun 7, 2011 at 11:41 AM, David Bruant david.bru...@labri.fr wrote:

  Le 06/06/2011 17:31, David Bruant a écrit :

 myWeakMap.set(key, value) doesn't return anything. It could return the
 previous value for the key (if such a thing exists). Is it intentional that
 the set function doesn't return anything?

 Anyone has thoughts on this point?

 Set and delete could return the weakmap.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: I noted some open issues on Classes with Trait Composition

[Juan Ignacio Dopazo]

On Thu, May 19, 2011 at 9:40 PM, Brendan Eich bren...@mozilla.com wrote:

 Not taking sides, just asking for you lurkers who use other libraries to do
 similar counting exercises with those libraries, if you all can spare the
 time. Thanks.


The reality is that in most cases libraries rarely use the constructor(x) {
this.x = x } pattern because they tend to create an abstraction to define
getters and setters through methods (usually get(prop) and set(prop,
value), but sometimes using getProp() and setProp(value)) and use an object
as a parameter instead of many parameters. Ie:

var widget = new Widget({
  content: 'hello world',
  title: 'example'
});

This is a very common pattern. Personally I always use it because for me
it's always easier to remember parameter names than parameter order. Of
course ES5's getters and setters change the situation a lot.


On a side note, there are a couple of aspects in the object initializer
extension proposal that I liked a lot and which value I think is being
underestimated. The class body similar to an object declaration with commas
and colons make it very easy to refactor a class into an object and
viceversa. This is not only useful for writing, but it also helps reading
because it relates complex objects and classes, which is what we're nowadays
doing with the most blogged about pattern in JS, the module pattern,
(function(){
return {} }()) and new function () {}.

Is a middle ground possible?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: I noted some open issues on Classes with Trait Composition

[Juan Ignacio Dopazo]

On Wed, May 18, 2011 at 4:10 PM, Bob Nystrom rnyst...@google.com wrote:

 On Wed, May 18, 2011 at 11:48 AM, Brendan Eich bren...@mozilla.com
  wrote:

 The whole of class declaration is a mouthful. 'function' and 'prototype'
 are overlong too.


 Sure. I'm not stuck on new, but in the chunks of sample code I've put
 together using constructor (which is what Traceur uses/did use for a good
 while) it did actually stick out as a syntactic wart, at least to me.

 Same with 'constructor', and that property must exist somehow. Why not be
 explicit and avoid having two names for one prototype property?

 3 is false in ES5. Reserved identifiers are valid property names. This is
 implemented in all the ES5-supporting browsers.


 Ah, my mistake. These are both fair points. It's too bad constructor is
 such a long word.

 Nowadays most libraries that implement some sort of class wrapping use
lengthy names for the constructor and it's not that bad.

Mootools
var Cat = new Class({
initialize: function(name){
this.name = name;
}
});

Prototype
var Cat = Class.create({
initialize: function(name){
this.name = name;
}
});

Dojo
var Cat = dojo.declare(null, {
constructor: function(name){
this.name = name;
}
});

YUI
var Cat = Y.Base.create('cat', null, [], {
initializer: function(name){
this.name = name;
}
});
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: arrow syntax unnecessary and the idea that function is too long

[Juan Ignacio Dopazo]

Since there's a call for developer feedback, I'll give mine.

Brendan once said JS is a curly-brace language and it always will be. I
think the - looks works very nice with a pythonic-like forced indentation
like Coffeescript has. However, I believe # looks better with curly braces,
so I'd keep #(x) { x * x }.

I also think familiarity should be considered and that #(x) { x * x } would
be more familiar to the casual JS programmer.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: extends keyword instead of superclass ...

[Juan Ignacio Dopazo]

I've been thinking about something Brendan said in his last podcast about
how the community and TC39 can't agree on the syntax for class initializers
because of how flexible he made it at the beginning. So a little idea came
to me.

How about adding an Object.getMetaProperties or Function.getMetaProperties
method to retrieve the meta properties of an object/class initializer,
regardless of where they were declared (inside or outside)? That way the
community could extend the syntax to fit different styles. Combined with
proxies it could lead to many different multiple inheritance or mixin
patterns, as well as other interesting applications I'm probably missing.

Of course, this would be extra useful if meta properties where defined
outside the class/object body, because there's not much difference between
writing

class A {
  superclass: B, uses: [C]
}

or

class A {
  superclass: B,
  class var USES: [C]
}

...as we do today using constructor properties to add extra functionality.

Being able to write somethink like...

class A uses [C, D] {
  new () {
let extensions = Function.getMetaProperty(A, 'uses') || [];
extensions.forEach(#(ext) {
// Copy ext prototype methods to A
});
  }
}

...could be useful and fun.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: extends keyword instead of superclass ...

[Juan Ignacio Dopazo]

Mixins are a great idea. Whatever decision is made about the position and
name of the inheritance declaration, they add a lot of value and are very
easy to understand.

A couple of related ideas:

class Vector {
superclass: Point, uses: Comparable
}

uses looks like a better fit. It's shorter and it's already used by many
documentation generators (YUI Doc comes to mind). Also, more than one mixin
could be easily added:

class Vector {
superclass: Point, uses: [Comparable, Measurable]
}

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: extends keyword instead of superclass ...

[Juan Ignacio Dopazo]

On Sat, Mar 26, 2011 at 6:31 PM, Dmitry A. Soshnikov 
dmitry.soshni...@gmail.com wrote:

 Why not just to use already reserved `extends` keyword for specifying a
 superclass? These XML-like braces looks not so elegant.


I asked this question a couple of days ago. The answer is quite simple.
Object initializer extensions are more than just constructor syntax. They
allow you to create complex objects without all the hassle in
(function(){}()). So the constructor syntax was made this way to be
consistent with object initializer syntax.

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: extends keyword instead of superclass ...

[Juan Ignacio Dopazo]

Sure, it was discussed in this thread
https://mail.mozilla.org/pipermail/es-discuss/2011-March/012963.html

https://mail.mozilla.org/pipermail/es-discuss/2011-March/012963.htmlJuan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extended Object Literals to review

[Juan Ignacio Dopazo]

One more question about the future of classes on Harmony.

Although the meta: property syntax is very clear, I'm wondering if it
isn't better to be less innovative and stick to what ES4/Java/etc have been
doing for a long time. Wouldn't something like this ease the learning curve
of the new features?

frozen class C extends S {
}

In this case frozen would apply to both the constructor, the prototype and
the instances created from the class. My guess is that most developers will
usually chose to apply a generic property instead of a more granular
approach (sealing only the prototype, etc). Of course, this could coexist
with meta: properties for when it is necessary to be more specific.

class C extends S {
  sealed: instance
}

Juan
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extended Object Literals to review

[Juan Ignacio Dopazo]

Absolutely not! I read the word meme and I panicked! Please understand
that I'm trying to write about highly technical topics in a foreign language
(I'm from Argentina), so sometimes my word choice may not be the best.

I used classes mostly because it's what most of JS developers I know use
today to talk about constructors. Some even talk about inheritance when just
using object composition (yes, you read right). I liked the constructor
keyword too. I thought it explained much better what was going on under the
hood. Too bad it is too long.

Consistency with extended object initializers makes a lot of sense. I hadn't
considered it.

Thanks for taking the time for explaining your reasoning! I'll do my best to
evangelize this vision.

Juan

On Tue, Mar 15, 2011 at 5:57 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:

 The starting point for the class initialiser proposal are the Object
 Initialiser Extensions.  I wanted to add the option to specify the prototype
 for  *ObjectLiteral* and *ArrayLiteral* but because they aren't prefixed
 by a keyword, the extends like syntax doesn't work for them.  The proto:
 foo syntax does.  If we accept that, then it seems to make sense to use a
 similar convention for Class Initalisers.  Put another way, I generally
 prioritize internal consistency ahead of similarity with other languages.

 There are both advantages and disadvantages to copying syntax from another
 language.  One of the disadvantages is familiar syntax creates an
 expectation for similar semantics.  JavaScript isn't Java and the objects
 defined by this proposal don't have the semantics of Java objects.  It may
 be a good thing if unfamiliar syntax causes a Java programmer to slow down a
 bit and think about what they really are defining.

 At a more meta level, I don't think about this proposal as adding classes
 to ECMAScript. I see it as adding syntax that more directly supports a
 common object usage patterns.  The extension doesn't add or change
 ECMAScript's fundamentally instance-based object model and it doesn't
 preclude other patterns of object-based inheritance or composition.  That
 was why in earlier iterations of this proposal I used the keyword
 constructor instead of class.

 BTW, the above is mostly a mild rant in reaction to your phrase the future
 of classes on Harmony.  I really hope that the meme doesn't get started
 that we're trying to remake JavaScript as a Java-style class-based language.
 I suspect you didn't mean that by the phrase, but I'm sensitive about how
 the things we talk about here and on the wiki are sometimes misinterpreted
 by members of the wider JavaScript community.

 Allen







 On Mar 15, 2011, at 12:46 PM, Juan Ignacio Dopazo wrote:

 One more question about the future of classes on Harmony.

 Although the meta: property syntax is very clear, I'm wondering if it
 isn't better to be less innovative and stick to what ES4/Java/etc have been
 doing for a long time. Wouldn't something like this ease the learning curve
 of the new features?

 frozen class C extends S {
 }

 In this case frozen would apply to both the constructor, the prototype and
 the instances created from the class. My guess is that most developers will
 usually chose to apply a generic property instead of a more granular
 approach (sealing only the prototype, etc). Of course, this could coexist
 with meta: properties for when it is necessary to be more specific.

 class C extends S {
   sealed: instance
 }

 Juan
 ___
 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: Extended Object Literals to review

[Juan Ignacio Dopazo]

@Brendan My mistake was thinking that setting enumerable to false also made
it return false on hasOwnProperty().

The idea behind it was to be able to walk down the prototype chain by doing
o.constructor.prototype.contructor.proto... But then I realized that's not
the case even in today's javascript.

Maybe adding a 'superclass' property to the constructor could be useful? As
in...

function S() {}
function C() {}
C.protototype = Object.create(S.prototype, { 'constructor': {value: C} });
Object.defineProperty(C, 'superclass', { value: S });

Juan

On Sun, Mar 13, 2011 at 6:16 PM, Brendan Eich bren...@mozilla.com wrote:

 On Mar 12, 2011, at 6:05 PM, Juan Ignacio Dopazo wrote:

 Right, my bad then.


 Maybe not, it's a difference but possibly someone will make the case for
 it. I still favor putting 'constructor' on the class prototype (constructor
 function .prototype in plain old ES5). It is more efficient and usually
 per-instance is neither wanted for some hasOwnProperty('constructor') must
 return true reason (presumably to prevent shadowing).

 If one wants higher integrity, Object.defineProperty(C.prototype,
 'constructor', {value:C, writable:false, configurable:false}} does the trick
 (that is verbose on purpose to be clear, there's a much shorter way to say
 it, using the default undefined-false conversions for missing attributes).

 Allen, did you want 'constructor' to be in the class prototype?

 /be


 Juan

 On Sat, Mar 12, 2011 at 8:37 PM, Brendan Eich bren...@mozilla.com wrote:

 On Mar 12, 2011, at 2:58 PM, Juan Ignacio Dopazo wrote:

  Correct me if I'm wrong, but I think it should be like this:
 
  function S() {}
 
  function C() {
Object.defineProperty(this, 'constructor', {
value: C,
enumerable: false,
writable: false,
configurable: false
});
  }
  C.prototype = Object.create(S.prototype);
 
  var o = new C();
  console.log(o.constructor == C); // true
  console.log(o.constructor.prototype.constructor == S); // true

 But this also puts an own property on every instance, which is not how
 .constructor works with functions:

 js function C(x) { this.x = x; }
 js c = new C(42)
 ({x:42})
 js c.hasOwnProperty('x')
 true
 js c.hasOwnProperty('constructor')
 false
 js c.constructor
 function C(x) {this.x = x;}
 js c.constructor === C
 true

 /be

 
  Juan
 
 
  On Sat, Mar 12, 2011 at 4:36 PM, Allen Wirfs-Brock 
 al...@wirfs-brock.com wrote:
  good point, the desugaring should be:
 
  function c() {};
  c.prototype=Object.create(s,protoype,{'constructor': { value:c,
 enumerable: false, writable: false, configurable:false}});
 
  We can debate about the attributes of the constructor (and the
 constructor's prototype) property but my stake in the ground is that these
 should be frozen because they are defined declaratively.
 
  On Mar 12, 2011, at 11:06 AM, Michael Haufe wrote:
 
  On Sat, Mar 12, 2011 at 11:02 AM, Allen Wirfs-Brock 
 al...@wirfs-brock.com wrote:
  [...]
   class c {
  proto: s.prototype
   }
 
   class c {
  superclass: s
   }
 
   both are equivalent to:
 
   function c() {};
   c.prototype=Object.create(s.prototype);
  [...]
 
  So if var b = new c, then b.constructor will be s instead of c?
 
 
 
 
  ___
  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




___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Extended Object Literals to review

[Juan Ignacio Dopazo]

Hi! I hope you don't mind a couple of questions about this proposal.

The superclass meta property definition says:

This causes the [[Prototype]] value of the new class’ prototype to be set to
 the prototype property value of the designated constructor function


Shouldn't the superclass' prototype be chained with the class' constructor
prototype instead of replacing it, as in Douglas Crockford's prototypal
inheritance article http://javascript.crockford.com/prototypal.html? I
believe this is easier to understand and less error prone, because when
modifying properties in the new class prototype they won't be added to the
superclass' prototype.

Why were class bodies chosen as object initializers instead of function
bodies? Function bodies allow for a couple of good concepts such as defining
private variables by default with the var statement, avoiding the use of the
this keyword for private variables and thus producing shorter code when
minified.

Also, what happens to methods in these proposal? Are they defined as
properties of the instance or as part of the prototype? If they are fresh
instance properties, is there a method for defining prototype methods when
using the superclass meta property?


Thanks! Harmony is looking awesome!
Regards,

Juan


On Wed, Mar 9, 2011 at 11:53 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:

 I've updated all of the Harmony extended object literal proposals
 http://wiki.ecmascript.org/doku.php?id=strawman:object_initialiser_extensions 
 based
 upon discussions at the last several TC39 meetings.  In particular a very
 productive informal discussion at the Sept. meeting.

 The major change in this iterations is a new class declaration based upon
 object literals. This declaration supports the declarative object definition
 that exactly mirrors the constructor/prototype/instance organization used by
 the EMAScript built-in objects.

 I also did some updates to the Private Names proposal
 http://wiki.ecmascript.org/doku.php?id=strawman:private_names to clarify
 some issues that have come up in previous meetings. There is also a proposal
 for integrating Private Names with the extended object literals.

 These items are on the agenda for the next TC39 meeting but discussion here
 is certainly welcome.

 Allen

 ___
 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: Extended Object Literals to review

[Juan Ignacio Dopazo]

Correct me if I'm wrong, but I think it should be like this:

function S() {}

function C() {
Object.defineProperty(this, 'constructor', {
 value: C,
enumerable: false,
 writable: false,
configurable: false
 });
}
C.prototype = Object.create(S.prototype);

var o = new C();
console.log(o.constructor == C); // true
console.log(o.constructor.prototype.constructor == S); // true

Juan


On Sat, Mar 12, 2011 at 4:36 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:

 good point, the desugaring should be:

 function c() {};
 c.prototype=Object.create(s,protoype,{'constructor': { value:c, enumerable:
 false, writable: false, configurable:false}});

 We can debate about the attributes of the constructor (and the
 constructor's prototype) property but my stake in the ground is that these
 should be frozen because they are defined declaratively.

 On Mar 12, 2011, at 11:06 AM, Michael Haufe wrote:

 On Sat, Mar 12, 2011 at 11:02 AM, Allen Wirfs-Brock al...@wirfs-brock.com
  wrote:
 [...]
  class c {
 proto: s.prototype
  }

  class c {
 superclass: s
  }

  both are equivalent to:

  function c() {};
  c.prototype=Object.create(s.prototype);
 [...]

 So if var b = new c, then b.constructor will be s instead of c?




 ___
 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: Extended Object Literals to review

[Juan Ignacio Dopazo]

Right, my bad then.

Juan

On Sat, Mar 12, 2011 at 8:37 PM, Brendan Eich bren...@mozilla.com wrote:

 On Mar 12, 2011, at 2:58 PM, Juan Ignacio Dopazo wrote:

  Correct me if I'm wrong, but I think it should be like this:
 
  function S() {}
 
  function C() {
Object.defineProperty(this, 'constructor', {
value: C,
enumerable: false,
writable: false,
configurable: false
});
  }
  C.prototype = Object.create(S.prototype);
 
  var o = new C();
  console.log(o.constructor == C); // true
  console.log(o.constructor.prototype.constructor == S); // true

 But this also puts an own property on every instance, which is not how
 .constructor works with functions:

 js function C(x) { this.x = x; }
 js c = new C(42)
 ({x:42})
 js c.hasOwnProperty('x')
 true
 js c.hasOwnProperty('constructor')
 false
 js c.constructor
 function C(x) {this.x = x;}
 js c.constructor === C
 true

 /be

 
  Juan
 
 
  On Sat, Mar 12, 2011 at 4:36 PM, Allen Wirfs-Brock 
 al...@wirfs-brock.com wrote:
  good point, the desugaring should be:
 
  function c() {};
  c.prototype=Object.create(s,protoype,{'constructor': { value:c,
 enumerable: false, writable: false, configurable:false}});
 
  We can debate about the attributes of the constructor (and the
 constructor's prototype) property but my stake in the ground is that these
 should be frozen because they are defined declaratively.
 
  On Mar 12, 2011, at 11:06 AM, Michael Haufe wrote:
 
  On Sat, Mar 12, 2011 at 11:02 AM, Allen Wirfs-Brock 
 al...@wirfs-brock.com wrote:
  [...]
   class c {
  proto: s.prototype
   }
 
   class c {
  superclass: s
   }
 
   both are equivalent to:
 
   function c() {};
   c.prototype=Object.create(s.prototype);
  [...]
 
  So if var b = new c, then b.constructor will be s instead of c?
 
 
 
 
  ___
  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


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss