Re: About Array.of()
My first post to this mailing list, so hi everyone! I agree with Domenic, Array.fromElements would be a good name (though I have no problem with Array.of). Just don't go with Array.new (I agree with Rick here, it should match the constructor - Array should be no exception, broken constructor or not)! / Mikael 2012/8/28 Domenic Denicola dome...@domenicdenicola.com Array.fromElements is solid, especially considering how rarely this will be used, especially given that it competes in ES6 code with `...x = [...x]` On Aug 27, 2012, at 23:42, 程劭非 csf...@gmail.com wrote: Yes, as a developer (but not English native speaker), I really feel uncomfortable with the name “of”. Considering we already have Object.create String.fromCharCode To keep align with them, I belive “create” or “fromElements” might be better choices. 2012/8/27 Shijun He hax@gmail.com: See the screenshots for the array of search suggestion in search engine. As a non-English native speaker, I'd like to say the search suggestion of array of in non-english languages seems most come from the programmers' input, so it shows how worldwide programmers think what array of means ;) On Mon, Aug 27, 2012 at 10:55 AM, Matthew Robb matthewwr...@gmail.com wrote: I agree with Rick on the general feeling with Array.of If arguing ambiguity I would argue a better method name for type guarded arrays would be Array.ofType On Sun, Aug 26, 2012 at 8:56 PM, Rick Waldron waldron.r...@gmail.com wrote: On Sunday, August 26, 2012 at 7:30 PM, Brendan Eich wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property name. It's darn nice for Rubyists. OTOH Array.of matches the preposition pattern used in Array.from. But I don't think this trumps Array.new. Nor do I, but I think it poses a problem for polyfilling (which is not a silver bullet). +1 Array.new, but I still think Array.of sounds, feels and looks nicer Rick Cc'ing Dave for his thoughts. /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 ___ 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: About Array.of()
On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote: Rick Waldron wrote: But Array.of is not. Maybe Array.new is a good name. Array.of is unambiguous with the current ES specification Array.new is ok too, though -- no problem with a reserved identifier as a property name. It's darn nice for Rubyists. Another possibility is Array.create, following the pattern of Object.create. of seems like a funky name for a constructor, to my taste. Cheers, Maciej ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
On Tue, Aug 28, 2012 at 9:59 AM, Maciej Stachowiak m...@apple.com wrote:
On Aug 26, 2012, at 4:30 PM, Brendan Eich bren...@mozilla.com wrote:
Rick Waldron wrote:
But Array.of is not. Maybe Array.new is a good name.
Array.of is unambiguous with the current ES specification
Array.new is ok too, though -- no problem with a reserved identifier as
a property name. It's darn nice for Rubyists.
Another possibility is Array.create, following the pattern of
Object.create. of seems like a funky name for a constructor, to my taste.
True, but I'd rather see Array.create as a fix for the one argument Array
constructor, i.e. creating an array of the specified length, without
holes. For example:
Array.create = function (length) {
if (length === 1) return [undefined]
return Array.apply(null, Array(length))
}
There's been some discussion of that earlier, actually [1].
My 2 cents goes to Array.fromElements, conveys very well what it does.
However, I'm still not quite sure what the use case is for this. For code
generation, if you know how many elements there are and what they are
enough to put them in the Array.of(...,...,...) call, why not just use
[...,...,...]? Unless it's supposed to be used for converting array-likes
to arrays, where I really don't think this is the best function signature.
For the dart example, why not just use [] and you avoid the gotcha?
Cheers,
Jussi
[1] https://mail.mozilla.org/pipermail/es-discuss/2012-July/023974.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
However, I'm still not quite sure what the use case is for this. For code generation, if you know how many elements there are and what they are enough to put them in the Array.of(...,...,...) call, why not just use [...,...,...]? Unless it's supposed to be used for converting array-likes to arrays, where I really don't think this is the best function signature. For the dart example, why not just use [] and you avoid the gotcha? map and map-like scenarios are another use case: [1,2,3].map(Array.of) // [[1], [2], [3]] But, as Domenic mentions, it does indeed compete with: [1,2,3].map(...x = [...x]) -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: About Array.of()
On Tue, Aug 28, 2012 at 12:40 PM, Axel Rauschmayer a...@rauschma.de wrote: However, I'm still not quite sure what the use case is for this. For code generation, if you know how many elements there are and what they are enough to put them in the Array.of(...,...,...) call, why not just use [...,...,...]? Unless it's supposed to be used for converting array-likes to arrays, where I really don't think this is the best function signature. For the dart example, why not just use [] and you avoid the gotcha? map and map-like scenarios are another use case: [1,2,3].map(Array.of) // [[1], [2], [3]] But, as Domenic mentions, it does indeed compete with: [1,2,3].map(...x = [...x]) Yeah, and in that case (making every element of an array an array), actually: [1,2,3].map(x = [x]) Which is even shorter. I really have a hard time seeing any value in having this feature. All the problems it's supposed to solve (at least the ones presented here) already have better solutions. :D Cheers, Jussi ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: A question about Loader baseURL
On Mon, Aug 27, 2012 at 11:38 PM, Shijun He hax@gmail.com wrote:
Example:
== my.js ==
var myLoader = new Loader(System, {fetch: myFetch}
function myFetch(relURL, baseURL, ...) {...}
myLoader.load('a/a.js', ...)
== a/a.js ==
import x from 'a/a.js' // developer means to load a/a/a.js
...
Right, and the sensible way to combine the baseURL
'http://example.com/a/a.js' and the relURL 'a/a.js' is to produce
'http://example.com/a/a/a.js', which is exactly what you want in this
case.
As I understand, imports in a/a.js (what in this case also import
another 'a/a.js' which should be resolve to 'a/a/a.js') will also
delegate to myLoader,
Exactly.
so it is obviously wrong if myFetch is invoked
with two identical arguments.
I don't see why that's wrong at all.
--
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A question about Loader baseURL
On Tue, Aug 28, 2012 at 7:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
As I understand, imports in a/a.js (what in this case also import
another 'a/a.js' which should be resolve to 'a/a/a.js') will also
delegate to myLoader,
Exactly.
so it is obviously wrong if myFetch is invoked
with two identical arguments.
I don't see why that's wrong at all.
For load('a/a.js') in my.js, myFetch is invoked with:
relURL='a/a.js'
baseURL = System.baseURL = '/path/my.js'
For import x from 'a/a.js', myFetch is also invoked with:
relURL='a/a.js'
baseURL = System.baseURL = '/path/my.js'
How myFetch can resolve identical envokes to different resouce?
--
sam th
sa...@ccs.neu.edu
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A question about Loader baseURL
For load('a/a.js') in my.js, myFetch is invoked with:
relURL='a/a.js'
baseURL = System.baseURL = '/path/my.js'
For import x from 'a/a.js', myFetch is also invoked with:
relURL='a/a.js'
baseURL = System.baseURL = '/path/my.js'
typo, both System.baseURL should read as myLoader.baserURL
How myFetch can resolve identical envokes to different resouce?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Function declaration in labelled statements
ES5 strict mode disallow Function declaration in any statements. It's
fine, but Function declaration in top labelled statements seems
harmless, why not relax the rules to allow them so we can use Labeled
Modules Specification ? Though it seems too late to fix.
Code example:
'use strict' // cause SyntaxError: In strict mode code, functions can
only be declared at top level or immediately within another function.
exports: function area(x1, y1, x2, y2){
return length(x1, x2) * length(y1, y2);
}
References:
Labeled Modules Specification:
https://github.com/labeledmodules/labeled-modules-spec
LMS implementation: https://npmjs.org/package/linkjs
my.js (ES6-like module system which utilize the same ideas from LMS
for import/export syntax): http://github.com/hax/my.js
--
hax
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Some questions about Private Name Objects
Apologies in advance for the length...
A huge share of this complexity has been removed in recent discussions
[1]. Conclusions seem to have reach consensus on es-discuss, but nothing
has been officially accepted by TC39
As I understand it, the solution arrived at was to provide a (possibly
updatable) collection of private name objects to the Proxy constructor and
let the engine take care of the details. That sounds good, and good work!
What do you mean? Private name allow to do mixins without collision. It
seems to reduce the complexity than increasing it in my opinion.
Unique (non-private) names offer mixins without collisions. But any
general mixin utility will fail if the source object relies on privately
named methods for its functionality:
// Create a private name
let privateMethodName = new Name();
// Create a class that naively defines and uses a privately-named
method
function A() {}
A.prototype.doSomething = function() { this[privateMethodName](); };
A.prototype[privateMethodName] = function() {};
// Create another class
function B() {}
// Attempt to mix A's functionality into B using a library function
mixin(A, B);
// Fails: privateMethodName is undefined
new B().doSomething();
Neither the destination object nor the library function mixin has access
to the private name, and therefore the privately named method will not get
copied to the destination object, and the mixin will fail.
Clearly the solution above would be to use a unique name, instead of a
private name. But that begs the question: why do we need private, secured
names at all? They complicate the object model without a compelling use
case, as far as I can tell. If there are use cases, let's see them.
In any situation where you want to *really* secure access to data or code,
the ergonomics of your code is going to be the least of your worries.
Security is just generally difficult, and that soft-tissue cost will
have to be borne by the developer whether they use WeakMaps or private
names or closures or whatever. Why complicate the object model, and in the
process invalidate the current maxim that all properties are reflective,
when the weight will still fall on the developer anyway?
Just an argument to consider...
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Function declaration in labelled statements
Shijun He wrote:
ES5 strict mode disallow Function declaration in any statements. It's
fine, but Function declaration in top labelled statements seems
harmless, why not relax the rules to allow them so we can use Labeled
Modules Specification ? Though it seems too late to fix.
It is, see below.
Code example:
'use strict' // cause SyntaxError: In strict mode code, functions can
only be declared at top level or immediately within another function.
exports: function area(x1, y1, x2, y2){
return length(x1, x2) * length(y1, y2);
}
This is a labeled named function expression statement, given a ; or ASI
after the closing brace. We can't change its meaning to declare a
function area, with hoisted name. That's an incompatible change, and
while it might seem unlikely to break any real code, you would be surprised.
People tend to make unnecessary labels, especially in event handlers
where javascript: at the front of the HTML attribute value has been seen
in the wild. Couple that with a function expression that is not
parenthesized, but possibly immediately invoked, and you have real trouble.
The grammatical problem is harder: we use lookahead restriction,
ExpressionStatement :
[lookahead ∉ {{, function}] Expression ;
to prevent a function expression from starting an expression statement.
To allow a labeled function declaration (not expression) we would have
to make this lookahead restriction conditional on whether the
ExpressionStatement is labeled.
Crock and I have proposed restricting labeled statements to those that
could use the label (not expression statements, currently; but block
lambdas could make this future-hostile, although we have nearly
unanimously ruled out Tennent's Correspondence Principle designs in the
future that want such a label-using block-lambda). See
http://wiki.ecmascript.org/doku.php?id=strawman:block_vs_object_literal
This looks like more trouble than it is worth, and again, it's an
incompatible change. Those rogue javascript: labels exist on the web.
/be
References:
Labeled Modules Specification:
https://github.com/labeledmodules/labeled-modules-spec
LMS implementation: https://npmjs.org/package/linkjs
my.js (ES6-like module system which utilize the same ideas from LMS
for import/export syntax): http://github.com/hax/my.js
--
hax
___
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: Some questions about Private Name Objects
Le 28/08/2012 15:38, Kevin Smith a écrit : Apologies in advance for the length... Don't. We're here to discuss as the mailing-list name suggests. And if what you need to say is long, so be it. A huge share of this complexity has been removed in recent discussions [1]. Conclusions seem to have reach consensus on es-discuss, but nothing has been officially accepted by TC39 As I understand it, the solution arrived at was to provide a (possibly updatable) collection of private name objects to the Proxy constructor and let the engine take care of the details. That sounds good, and good work! Exactly. I'm glad there is one more fan of the proposal :-) What do you mean? Private name allow to do mixins without collision. It seems to reduce the complexity than increasing it in my opinion. Unique (non-private) names offer mixins without collisions. But any general mixin utility will fail if the source object relies on privately named methods for its functionality: (code snippet) Neither the destination object nor the library function mixin has access to the private name, and therefore the privately named method will not get copied to the destination object, and the mixin will fail. Clearly the solution above would be to use a unique name, instead of a private name. Indeed. But that begs the question: why do we need private, secured names at all? They complicate the object model without a compelling use case, as far as I can tell. If there are use cases, let's see them. Private names enable easy encapsulation code sharing at the same time (which is awkward at best nowadays). As a result of the current awkwardness, developer sacrifice encapsulation by using publicly accessible fields using the _field convention. I could name dozens of Node.js library doing that. And sometimes, developers use a private field while they shouldn't, but it makes their life easier, and abstraction leak, etc. It all start because of a fundamental missing piece in the language that is the ability to add a private property to an object. Not socially private as per the _field convention. I mean actually private, enforced by the runtime. In any situation where you want to *really* secure access to data or code, the ergonomics of your code is going to be the least of your worries. I disagree. A good part of the work toward securing an application is reviewing it. The easier the review is, the less likely you are to leave holes behind. The ergonomics of the code is a security feature. Security is just generally difficult, and that soft-tissue cost will have to be borne by the developer whether they use WeakMaps or private names or closures or whatever. Why complicate the object model, and in the process invalidate the current maxim that all properties are reflective, when the weight will still fall on the developer anyway? I arrived on es-discuss at a time where private names had been decided to be the mecanism that answer all above-listed constraints. It seems to do the job. I have intuitive concerns about how to use them in large scale applications and preserve proper code sharing, but nothing concrete to either validate nor invalidate this intuition. In a nutshell, I'm wondering whether private names will be easy to use in complex cases. I'm not specifically against the idea of complicating the object model if the benefit is developers stopping _fields. I am open anyway to see if there is an idea that's alternative to private name and would solve all above constraints. There is still time since no one has implemented private names (or symbols as it's their new name which I'm still not used to) yet. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
export questions
Four things: 1) The export grammar on the wiki allows: export *; Which I take to mean export every local binding. What's the justification? I don't think I've ever seen a ES5 module that didn't have some local, non-exported state or function. 2) The grammar also allows: export * from Path.To.Module; which is fine. But I think it would also be convenient to provide the following: export * from SomeModule.js; In particular, this form would be useful in package main files, where you are combining the interface of several sub-modules into a single package interface. Using only the allowed forms, we would need something like: import SomeModule.js as SomeModule; export * from SomeModule; 3) I really like the module syntax (except for import *), and I would like to see convergence on the syntax for importing to a module instance: import SomeModule.js as SomeModule; // or module SomeModule = SomeModule.js; I personally like the former, but has there been any agreement on either one? Until there's a decision, we can't proceed with bleeding-edge transcompilation. : ) 4) Just a comment: the main argument in favor of import * is convenience. But it's nearly as convenient to import to a module instance: import A.js as A; A.x(); A.y(); This is indeed what Node.js programmers are used to and I don't believe there has been any gnashing of teeth over it. In my opinion, being able to statically analyze a module in isolation outweighs the additional convenience of import *. Thanks for your time! Kevin ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Some questions about Private Name Objects
Unique (non-private) names offer mixins without collisions. But any general mixin utility will fail if the source object relies on privately named methods for its functionality: ... Neither the destination object nor the library function mixin has access to the private name, and therefore the privately named method will not get copied to the destination object, and the mixin will fail. Clearly the solution above would be to use a unique name, instead of a private name. Alternatively, and this has a more OOP feeling to it, one could put the objects in control of iterations, with separate, overridable iterators for separate purposes. One such purpose would be an iterator to be used for an object clone/extend operator. The default clone iterator would skip private properties, but those could be added by overriding. Such a clone operator would itself need to be private, only callable for property copying (eg, with a built-in extend), but with this caveat, it should be possible to copy private properties without exposing their keys, and with the source object in full control of whether or not private properties may be copied. Is this line of reasoning too far off, or has it been considered to add such extend/clone iterators? Claus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Convergence options for Ecmascript/Actionscript?
Hope this isn't politically inappropriate here;-) 1. Flash is dying as a browser plugin, but otherwise still alive, especially with compilation of Actionscript to native code [2,3]. 2. Adobe has been growing support for HTML/Javascript options. 3. Actionscript is based on an old ES draft standard that failed to reach consensus, partly because its changes were considered too much at once. [my impression - I don't have a reference] 4. Lots of Actionscript developers find themselves having to grow accustomed to the world of HTML/Javascript One consequence of 4 are blog posts about Javascript technology X, for Flash developers. When I read such blog posts (eg, [1], with side-by-side comparisons of AS and JS code), I get the feeling that the transition would be much easier from AS3 to ES6, where things like modules and minimal classes exist. There is an opportunity here, if those parts of the standard are sufficiently stable to recommend transpiling (until real ES6 implementations come along). One consequence of 3 is that there should be a vibrant community of AS developers who have practical experience with features similar to those considered for ES6, in a Javascript-like language. Yet I do not see any experience reports or spec feedback based on that here on this list. Wouldn't it be very helpful to invite such input? I don't expect Actionscript developers want to lose any of their language features, but there might be profit (for both AS and ES developers) if Adobe could try to align AS4 to ES6 so that the common language subsets have common syntax and semantics. Such a hypothetical AS4 would be a typed version of ES6, making it easier for Adobe's tools to support both, and making it easier for developers to use or maintain either. Are there any Adobe folks listening here? Does anyone have the contacts to raise the question with them? Do you agree that there is potential for useful exchange of information and joining of efforts if the wall between AS and ES could be lowered? And no, I'm not a Flash/Actionscript developer. I just keep encountering cross-references, and thought I'd bring up the topic. Claus http://clausreinke.github.com/ [1] http://jessewarden.com/2012/08/backbone-js-for-flash-and-flex-developers.html [2] http://www.mikechambers.com/blog/2011/11/11/clarifications-on-flash-player-for-mobile-browsers-the-flash-platform-and-the-future-of-flash/ [3] http://blogs.adobe.com/conversations/2011/11/flash-focus.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
new strawman: syntactic support for private names
The strawman is at http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: new strawman: syntactic support for private names
Couldn’t you have the same advantages if: - obj.@foo was syntactic sugar for obj[foo] - @foo was syntactic sugar for [foo] (method definitions, property definitions, etc.) foo would be a normal variable and the following two statements would be equivalent: private foo; let foo = new Name(); foo containing a string would also work. That would be slightly simpler and go together well with your proposed object model reformation [1]: https://gist.github.com/3505466 [1] http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation On Aug 29, 2012, at 1:04 , Allen Wirfs-Brock al...@wirfs-brock.com wrote: The strawman is at http://wiki.ecmascript.org/doku.php?id=strawman:syntactic_support_for_private_names Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Dr. Axel Rauschmayer a...@rauschma.de home: rauschma.de twitter: twitter.com/rauschma blog: 2ality.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Convergence options for Ecmascript/Actionscript?
Claus Reinke wrote: Hope this isn't politically inappropriate here;-) 1. Flash is dying as a browser plugin, but otherwise still alive, especially with compilation of Actionscript to native code [2,3]. 2. Adobe has been growing support for HTML/Javascript options. 3. Actionscript is based on an old ES draft standard that failed to reach consensus, partly because its changes were considered too much at once. [my impression - I don't have a reference] You really should read back in es-discuss if you have time (understand if you don't!). We covered what made ES4 fail. The main problem was namespaces, upon which packages were built. Unfortunately, AS3 uses namespaces and packages heavily. Mozilla's Shumway project includes an AS3 bytecode recompiler that generates JS, and we cannot lower namespaces to anything native and JIT-optimized in JS itself. Cc'ing Tobias in case he can comment. 4. Lots of Actionscript developers find themselves having to grow accustomed to the world of HTML/Javascript Developers do adapt, of course. One consequence of 4 are blog posts about Javascript technology X, for Flash developers. When I read such blog posts (eg, [1], with side-by-side comparisons of AS and JS code), I get the feeling that the transition would be much easier from AS3 to ES6, where things like modules and minimal classes exist. There is an opportunity here, if those parts of the standard are sufficiently stable to recommend transpiling (until real ES6 implementations come along). Namespaces and packages are the problems (really one problem, namespaces making lookup three dimensional rather than two dimensions (proto and scope chain). One consequence of 3 is that there should be a vibrant community of AS developers who have practical experience with features similar to those considered for ES6, in a Javascript-like language. Not similar enough, in my view. Not only does AS3 have namespaces, it uses them for class-private and IIRC protected visibility. IIRC AS3 classes do not have class-side inheritance (just like Java), another difference. Finally, AS3 was really intended, along with an implicitly early-bound namespace, to statically judge the meaning of names and even types. Its code loading and global object model is entirely unlike the Web's. Yet I do not see any experience reports or spec feedback based on that here on this list. Wouldn't it be very helpful to invite such input? I think not. Some of us were involved intimately in ES4. We have the scars and remember the differences. ES6 does not need more constraints or feature demands from newcomers. That is a sure way to kill it. I don't expect Actionscript developers want to lose any of their language features, but there might be profit (for both AS and ES developers) if Adobe could try to align AS4 to ES6 so that the common language subsets have common syntax and semantics. That's up to Adobe, but I recall that they are talking about going more their own way: http://www.kirupa.com/forum/showthread.php?371078-ActionScript-quot-Next-quot-Flash-Roadmap Such a hypothetical AS4 would be a typed version of ES6, making it easier for Adobe's tools to support both, and making it easier for developers to use or maintain either. No typed (static) version can work interoperably and soundly with the dynamic language. This was one of the conclusions of the ES4 work. How to interface typed and untyped (dynamically typed) code is still research. Sam Tobin-Hochstadt's Typed Racket work is one example of research along the lines of interconnecting dynamic and static code without losing soundness. Even throwing out soundness may break interop. We'll see how this works for Dart, but right now Dart is a dynamic language with an early warning system. Are there any Adobe folks listening here? Does anyone have the contacts to raise the question with them? Do you agree that there is potential for useful exchange of information and joining of efforts if the wall between AS and ES could be lowered? Adobe folks departed the Ecma TC39 field, although IIRC Adobe remainds a member of www.ecma-international.org. Again I must comment that ES6 wants no new constraints and pressures. Scope creep is the enemy. Also, you should not ignore the ES4 lessons learned or assume the problems were not material and inherent to the divergence between AS3 and ES3. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Convergence options for Ecmascript/Actionscript?
On Tue, Aug 28, 2012 at 8:30 PM, Brendan Eich bren...@mozilla.org wrote: Claus Reinke wrote: Hope this isn't politically inappropriate here;-) 1. Flash is dying as a browser plugin, but otherwise still alive, especially with compilation of Actionscript to native code [2,3]. 2. Adobe has been growing support for HTML/Javascript options. 3. Actionscript is based on an old ES draft standard that failed to reach consensus, partly because its changes were considered too much at once. [my impression - I don't have a reference] You really should read back in es-discuss if you have time (understand if you don't!). We covered what made ES4 fail. The main problem was namespaces, upon which packages were built. Unfortunately, AS3 uses namespaces and packages heavily. Mozilla's Shumway project includes an AS3 bytecode recompiler that generates JS, and we cannot lower namespaces to anything native and JIT-optimized in JS itself. Cc'ing Tobias in case he can comment. 4. Lots of Actionscript developers find themselves having to grow accustomed to the world of HTML/Javascript Developers do adapt, of course. One consequence of 4 are blog posts about Javascript technology X, for Flash developers. When I read such blog posts (eg, [1], with side-by-side comparisons of AS and JS code), I get the feeling that the transition would be much easier from AS3 to ES6, where things like modules and minimal classes exist. There is an opportunity here, if those parts of the standard are sufficiently stable to recommend transpiling (until real ES6 implementations come along). Namespaces and packages are the problems (really one problem, namespaces making lookup three dimensional rather than two dimensions (proto and scope chain). One consequence of 3 is that there should be a vibrant community of AS developers who have practical experience with features similar to those considered for ES6, in a Javascript-like language. Not similar enough, in my view. Not only does AS3 have namespaces, it uses them for class-private and IIRC protected visibility. IIRC AS3 classes do not have class-side inheritance (just like Java), another difference. Finally, AS3 was really intended, along with an implicitly early-bound namespace, to statically judge the meaning of names and even types. Its code loading and global object model is entirely unlike the Web's. Yet I do not see any experience reports or spec feedback based on that here on this list. Wouldn't it be very helpful to invite such input? I think not. Some of us were involved intimately in ES4. We have the scars and remember the differences. ES6 does not need more constraints or feature demands from newcomers. That is a sure way to kill it. I don't expect Actionscript developers want to lose any of their language features, but there might be profit (for both AS and ES developers) if Adobe could try to align AS4 to ES6 so that the common language subsets have common syntax and semantics. That's up to Adobe, but I recall that they are talking about going more their own way: http://www.kirupa.com/forum/**showthread.php?371078-** ActionScript-quot-Next-quot-**Flash-Roadmaphttp://www.kirupa.com/forum/showthread.php?371078-ActionScript-quot-Next-quot-Flash-Roadmap Such a hypothetical AS4 would be a typed version of ES6, making it easier for Adobe's tools to support both, and making it easier for developers to use or maintain either. No typed (static) version can work interoperably and soundly with the dynamic language. This was one of the conclusions of the ES4 work. How to interface typed and untyped (dynamically typed) code is still research. Sam Tobin-Hochstadt's Typed Racket work is one example of research along the lines of interconnecting dynamic and static code without losing soundness. Even throwing out soundness may break interop. We'll see how this works for Dart, but right now Dart is a dynamic language with an early warning system. Are there any Adobe folks listening here? Does anyone have the contacts to raise the question with them? Do you agree that there is potential for useful exchange of information and joining of efforts if the wall between AS and ES could be lowered? Adobe folks departed the Ecma TC39 field, although IIRC Adobe remainds a member of www.ecma-international.org. Again I must comment that ES6 wants no new constraints and pressures. Scope creep is the enemy. Also, you should not ignore the ES4 lessons learned or assume the problems were not material and inherent to the divergence between AS3 and ES3. I know that Divya Manian (left Opera to join Adobe a few months ago) was interested in possibly reviving Adobe's TC39 involvement—but not at all on behalf of AS3 (4?) developments. Adobe has a lot of momentum building around their newer JavaScript based HTML5 products, so my guess is that if there is any renewed interest will arise from that.
Re: Experimental implementation of Object.observe JS Utilitylibrary now available
Hi François, Thanks so much for your thoughtful consideration of the Object.observe() proposal. Here's my take on your counter-proposal: Interestingly, what you've focused on is the one thing we intentionally left out of the Object.observe() proposal, namely: observing computed properties. In that way, I don't see what you've proposed as an alternative, but rather supplementary. First, I'd like to point out that, while most people these days seem to say databinding and specifically mean updating a UI, there are important use cases which depend on observing mutations to objects which are entirely distinct. Note that what you've proposed, doesn't include the following abilities: 1) Discovering when new properties are added to objects -- which is particularly important in the case of Arrays, where you often want to bind to the *set* of elements in an Array 2) Knowing the order of changes which occurred -- this is important to many use cases, including persisting changes to domain objects and efficiently computing effective changes to complex data structures (a DOM tree implemented in JS would be one example). 3) Discovering when properties have been reconfigured -- which is important if your strategy for observing computed properties is comparatively expensive, and you need to know *when* to employ it. 4) Generally, having full knowledge of what happened to an object so as to able to efficiently mirror it -- which is important in some synchronization strategies. Ok, with that out of the way, I think the topic you've raised: computed properties, deserves its own thread -- so I'll start a new thread for that purpose and put my thoughts there. On Sun, Aug 26, 2012 at 6:14 AM, François REMY fremycompany_...@yahoo.fr wrote: Here’s my take on the binding thing: http://fremycompany.com/BG/2012/ECMAScript-Binding-Manager-951/ Key features: - Do not require to have a reference on an object to bind to it (binding is implicit and managed by the browser). - Accessors, function calls and inner dependencies are managed automatically. - Since the browser manage most the binding wiring, it can makes tons of optimizations. - It’s trivial to use for developers. Have a look ;-) From: Alex Russell Sent: Thursday, August 23, 2012 11:47 AM To: Brandon Benvie Cc: ste...@stevensanderson.com ; es-discuss@mozilla.org Subject: Re: Re: Experimental implementation of Object.observe JS Utilitylibrary now available On Thu, Aug 23, 2012 at 7:06 AM, Brandon Benvie bran...@brandonbenvie.com wrote: I would say it is most definitely not the concern of Observe to watch reads and between accessors and Proxies we have all the tools we need for that. I think that misreads the situation. Having proxies available might work for this, but is it the right (implied) *UI* for it? I.e., if you need to do half of your work with observe() and then pivot over to proxies for the other half...that strikes me as strange. There might be good reasons not to, but saying you can do it with what we've got is always tautological in a turing machine = ) With the ability to keep present on notifications of changes via observe it's actually possible to implement a mirror that can be emit change events (by explicitly mirroring changes on the original target changes) and provide the benefits of the observe api to listeners, and then implement any kind of additional tracking on top of that either by using accessors or being a proxy. ___ 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object.observe and observing computed properties
Steve Sanderson (author of the excellent KnockoutJS framework) and
François REMY both raised the issue of observing computed properties
WRT to the Object.observe() proposal.
Having thought about this problem while helping to author
Object.observe, my thoughts are as follows:
First, I think you need to look at the problem the right way.
Observing computed properties is kind of non-sensical. What this
translates to is observe when the *return value* of an anonymous
function invocation *will be* different from the last invocation.
I think the only reasonable way to look at it is this: imagine that a
*data property* can be defined whose value can only be set by
assigning it the return value of a given function. Observing when a
data property changes value is trivial. The problem becomes: deciding
when the function should be re-evaluated.
Looked at like this, the first thing that becomes obvious is that
there are a class of functions which should never be used: those
functions that can spontaneously change value. e.g.
var i = 1;
function getVal { return ++i; }
function getVal2 { return Math.random(); }
function getVal3 { return myElement.offsetHeight; }
[I actually think at this point it becomes clear that, because the
task at hand isn't solvable in general, it's not appropriate to
include support for it at the language level, but lets continue].
That said, those functions:
-whose output is dependent only on the value of a discrete set of
inputs, (i.e. are stateless)
-don't modify their inputs
-will always return the same output value for the same set of inputs
can be sensibly used for computed property functions. It's worth
noting that even this can be easy to get wrong. For example, many
webdevs might not realize that
var firstName = 'Rafael';
var lastName = 'Weinstein';
function getVal() { return [firstName, lastName]; }
doesn't meet this criteria as its return value is always a different
Array object.
Assuming that you've been careful to pick an appropriate function,
there are two approaches to knowing when to reevaluate it:
1) Dirty-checking: Immediately before each time you need the value
of the dependent property.
2) Dependency observation: When one or more of its inputs have changed value.
At this point, you have only trade-offs. (1) Is potentially expensive
and hard to do at exactly the right time, but (2) requires having
proper knowledge of the function's inputs.
Obtaining the set of inputs for (2) can be done in two ways:
2a) Require the function author to declare them.
2b) Attempt to discover them by running the function and observing
which inputs it accesses.
(2a) requires some careful attention on the part of the function
author, so in some sense, if (2b) were possible, it would be ideal.
This brings us to what KnockoutJS does and what François proposed, so
let's consider it.
The first problem is what I discussed above, that creating an
*appropriate* function is potentially tricky and/or hard to
understand, and there isn't any way to statically determine if a
function is or is not appropriate.
The second problem is that doing this risks discovering inputs that
aren't really inputs at all. In other words, the function, just be
being invoked happens to touch a wide swath of objects, even though
they aren't dependencies of the function. This is bad because it would
cause the system to observe these objects, which, given modern VMs,
will cause them to de-optimize and become slower to access
Thus, offering language-level support for (2b) puts developers in the
risky situations of authoring computed property functions which may
A) not fire their notifications, even though they appear to have changed value
B) become a go-slow button for their entire application
...with no good recourse to discover why either is happening.
Note that François's proposal included a mitigation of (B), in that
you need to whitelist objects as potential discoverable dependencies.
This helps some with the risk of discovering too many dependencies,
but it also risks not discovering enough dependencies, which becomes
problem (A) again.
Thus, what we have is a problem which is really solved through
convention, not through an abstract solution, and thus the most
sensible thing to do is leave it to authors to make trade-offs for
themselves about the pros cons of the various approaches and the
conventions they imply.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
