Re: Typo in direct proxy proposal for the apply trap
Le 02/09/2012 23:13, Brandon Benvie a écrit : The use of the term receiver is somewhat misleading when put next to the receiver in the get and set traps. For get and set the receiver is always the proxy unless it's an object that has the proxy as its [[prototype]]. For function invocation the receiver is the callsite object which is never going to be the proxy itself (unless you did something like fnproxy.call(fnproxy). Indeed. I spent some time yesterday playing with the direct proxy Firefox implementation and adjusting the Proxy doc on MDN [1] (which is why I spammed es-discuss with proxy-related topics). I chose not to use receiver in the doc, but thisValue instead. David [1] https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Convergence options for Ecmascript/Actionscript?
Thanks everyone for your feedback! I certainly learned a thing or two, but the majority opinion and information seem to be: - further divergence is in the cards for AS and ES - AS and ES are already so different that, wrt input to ES development, AS has no special status over other languages (no close cousin) - asking AS developers for input is likely to be unhelpful - getting AS3 developers who want/have to switch to look at ES6 instead of ES5 is unnecessary - AS3 developers who have switched to ES5 may not differ in their suggestions from other ES5 developers - Adobe's growing HTML5/JS efforts are disconnected from AS evolution Independent of all this, there is no barrier to communication between the developers of AS3/4 and ES5/6, so if there was useful input to be had, it could flow freely. And a few readers here have experience from both sides. Thanks again, Claus PS. I tried to keep the tool platform out of this, as it isn't the right list, but some replies were concerned about this aspect, so I'd like to mention ongoing efforts to export from Flash-related toolchains to HTML5/JS, including Adobe's Edge tool and the Flash to CreateJS export plugin: http://labs.adobe.com/technologies/edge/ http://www.adobe.com/products/flash/flash-to-html5.html Other projects are adding JS backends or are offering conversions. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Experimental implementation of Object.observe JS Utilitylibrarynow available
+1 for makeObservable On Fri, Aug 31, 2012 at 10:41 AM, François REMY fremycompany_...@yahoo.frwrote: From: Rick Waldron Nit: Object.makeBindable sounds like: prepare this for bindability, but bind is already a concept in the language, where Function.prototype.bind creates a new function object from an existing function object, but with a BoundThis as specified by the thisArg in fn.bind( thisArg ); You've a point. Object.makeObservable() may be better, indeed. __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: export questions
On Fri, Aug 31, 2012 at 6:24 PM, 程劭非 csf...@gmail.com wrote:
What does it look like if you want to import more than one variables
from one module?
import {a,b} from oldscript.js#a,b
2012/8/31 Shijun He hax@gmail.com:
On Fri, Aug 31, 2012 at 3:16 PM, 程劭非 csf...@gmail.com wrote:
I guess Kevin has some same concerns with me.
The four things point to one question: What should we do with the old
ES3/ES5 libraries after we have module?
(please correct me if you didn't mean that.)
ES3/ES5 libraries might be in more than one files and there are no
“export” and import in it.
For example, I might want to use jQuery 1.3.2 in ES6, and I might
could not modify the .js file for some reason.
I might want the following thing:
-
import http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js;
as jQuery
var $ = jQuery.$;
-
I'm using this pattern from 2006:
$import(jquery.min.js#jQuery,$)
translate to ES6 syntax:
import {$} from jquery.min.js#jQuery
That is, use URI fragment to identify the export names for old scripts.
The loader will run the scripts in a sandbox and only export the
specified names.
This can be achieved in customized loader in current draft.
var myLoader = new Loader(System, {
translate: function(src, relURL, baseURL, resolved) {
var frag = new URL(relURL).fragment // URL class parse the url
to uri components
if (frag == null) return src
var exportNames = src.split(/\s*,\s*/)
return wrap(src, exportNames) // wrap the src with AMD-style
function wrapper
}
})
But maybe System loader could support it directly.
And, a library might have dependencies, and they might not be using
ES6 modules to manage their dependencies, I might want the following
thing:
-
import jquery.min.js, MyES5Module.js as MyES5Module
var dosth = MyES5Module.dosth;
-
Currently harmony:modules might not strong enough to cover these
cases. My proposal is :
1. Export every thing by default.
Since we have import ... from ... to protect our namespace there is
no need to use “export”. If any author of library would like to hide
local variable they will use anonymous function.
2.Allow multiple files in a module
in Variant A: import URL syntax
ModuleImport ::= StringLiteral as Id
===
ModuleImport ::= StringLiteral (, StringLiteral)* as Id
2012/8/29 Kevin Smith khs4...@gmail.com:
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
___
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: i18n API - Intl object.
On Friday, 31 August 2012 at 17:04, Norbert Lindenberg wrote:
It takes a few steps to find the information, but I think the
Internationalization API spec together with the Language spec cover this:
Clause 8 of the Internationalization API spec says: The Intl object is a
standard built-in object that is the initial value of the Intl property of
the global object.
Clause 7 of the Internationalization API spec says: Unless specified
otherwise in this document, the objects, functions, and constructors
described in this standard are subject to the generic requirements and
restrictions specified for standard built-in ECMAScript objects in the
ECMAScript Language Specification 5.1 edition, introduction of clause 15, or
successor.
Clause 15 of the Language spec says: Every other property described in this
clause has the attributes { [[Writable]]: true, [[Enumerable]]: false,
[[Configurable]]: true } unless otherwise specified.
Ergo: The Intl property of the global object has the attributes {
[[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
Thanks for the clarification. Hopefully a HTML version of the i18n spec can
also be published that links to the right places in the Lang spec. Makes the
jumping around easier :)
--
Marcos Caceres
http://datadriven.com.au
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: i18n API - Intl object.
On Monday, September 3, 2012 at 8:28 AM, Marcos Caceres wrote:
On Friday, 31 August 2012 at 17:04, Norbert Lindenberg wrote:
It takes a few steps to find the information, but I think the
Internationalization API spec together with the Language spec cover this:
Clause 8 of the Internationalization API spec says: The Intl object is a
standard built-in object that is the initial value of the Intl property of
the global object.
Clause 7 of the Internationalization API spec says: Unless specified
otherwise in this document, the objects, functions, and constructors
described in this standard are subject to the generic requirements and
restrictions specified for standard built-in ECMAScript objects in the
ECMAScript Language Specification 5.1 edition, introduction of clause 15,
or successor.
Clause 15 of the Language spec says: Every other property described in
this clause has the attributes { [[Writable]]: true, [[Enumerable]]: false,
[[Configurable]]: true } unless otherwise specified.
Ergo: The Intl property of the global object has the attributes {
[[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true }.
Thanks for the clarification. Hopefully a HTML version of the i18n spec can
also be published that links to the right places in the Lang spec. Makes the
jumping around easier :)
Agreed. Cc'ing Jason Orendorff
Norbert, perhaps you could work with Jason to export the i18n spec to HTML, as
he has a tool that (not quite automatically) converts to HTML. I know that he
and Allen produced the ES6 in HTML as well
Rick
--
Marcos Caceres
http://datadriven.com.au
___
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: i18n API - Invalid option values should not throw
(accidentally left out es-discuss when I responded to Norbert… response if
below)
On Monday, 3 September 2012 at 13:20, Marcos Caceres wrote:
Hi Norbert,
On Saturday, 1 September 2012 at 00:31, Norbert Lindenberg wrote:
On Aug 31, 2012, at 7:17 , Marcos Caceres wrote:
The way I understand it, backwards compatibility means that code that runs
on an old version without exceptions continues to run on the new version
with the same results. It does not mean that code that takes advantage of
new capabilities in the new version will get the same results on the old
version.
You are correct, lets call this graceful degradation or fault tolerance. I
guess it does not matter what we call it, so long as it's understood that
desired behaviour is that the API continues to work on old runtimes when if
new options are made available without significant code changes (such as
wrapping code in try/catch blocks).
Bogus hypothetical example - ES i18n.next introduces formal, where the
day always has the first letter capitalised:
{day: formal}
Let's assume weekday - the day property currently has only numeric and
2-digit, therefore no letters.
Because of this throw behaviour, the introduction of formal in a future
spec would potentially break all existing implementations today. If this
behaviour is left as is, (1) all calls to the i18n API will need to be
wrapped in try/catch (as a preemptive measure as the introductions of a
new option value would cause a throw). As a side effect, (2) users on old
browsers could be negatively impacted in the future without the knowledge
of the developer.
Applications only have to wrap their calls in try/catch if they use a new
option value and want to run on old browsers that may not understand the
new value.
The problem with the above is that the developer may not even know that the
API throws - if the developer runs their code on only browsers that support
formal then she would never know there was a problem. The above also
assumes the code is being maintained by the developer. The developer may
choose not to care about particular users or may not have access to (or even
be aware of) their application failing on particular browsers.
As I've stated before, the current API design is allowing developers to
unknowingly exclude users. By simply providing a fallback, this problem goes
away.
It's similar to how they have to check whether new API exists if they want
to run on browsers that may not have that API yet.
I don't think the API design should rely on workarounds that have emerged to
overcome issues with the Web platform (i.e., feature testing and duck typing
are in many ways a failing of the platform, and not something that should be
built on, IMHO). APIs should not rely on having to be wrapped in support
checking code as it makes code much more inefficient, harder to read, and
less maintainable. Compare:
//always gonna get something the user understands…
var ldate = (new Date()).toLocaleString(en, {day: formal});
To:
if(window.Intl !== undefined){
try{
var ldate = (new Date()).toLocaleString(en, {day: formal});
}catch(e){
//ok, gotta try something else…
...
}
}
Also, feature detection is usually done at the most basic level: like
window.hasOwnProperty(Intl); and not try/catch every possible option in the
an API. Take a look at Modernizr:
http://modernizr.com/downloads/modernizr.js
Most tests are pretty simple (in a good way): in as far as they most just
test if (x in y) return true/false. In most cases, actual functionality is
not tested - just presence of a given host object, method, or attribute.
Applications probably also would not have to wrap all calls - I think
modern applications run a sequence of tests early on to detect which of the
features they want to use are supported, and then adjust their behavior
accordingly (polyfill, dumb down, ask the user to upgrade, ...).
This assumes a lot of sophistication on the part of developers. History shows
that most developers don't do unit testing or any other kind of testing.
The API should make no assumptions about the code around it - the assumed
context should not matter (i.e., wrapped in try/catch or not should not
factor into the API design). To be clear: the API should be designed to be
testable, but it should be assumed that it will *not* be tested.
In this specific case, checking whether formal is supported also lets
applications decide what to do if formal is not supported.
This assumes that runtimes are the same across platforms or that the
developer has access to all the platforms on which she is required to test.
Most likely, it would choose long instead because it's closer to formal
than numeric, which would be the default used by the implementation.
Re: ECMAScript collation question
The BCP 47 Unicode Locale Extension would need it, and currently that's tangled with CLDR... Norbert On Sep 2, 2012, at 16:49 , Markus Scherer wrote: On Sun, Sep 2, 2012 at 12:51 PM, Mark Davis ☕ m...@macchiato.com wrote: We could propose to the CLDR group adding attribute=default to mean (for CLDR) the same as missing (at least for kk, if not others). I don't think that CLDR needs that just because ECMAScript might have it. markus ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
