John Barton wrote:
The biggest problem with this test is that the Alexa set selects for sites
with experienced developers writing for production sites. The pattern you are
trying to detect is not used in these circumstances.
I agree that this dataset is not representative of all JS code.
On Mar 6, 2014, at 10:07 AM, Brian Terlson wrote:
Chakra, and other implementations I imagine, will remove features that are
non-standard and are unused. Getting usage data is the hard part, so anything
concrete anyone can share would be helpful. I am in favor of removing this if
we can
If you use a getOwnPropertyNames trap, then you also need a
getOwnPropertySymbols trap to implement getOwnPropertyDescriptors.
--scott
On Thu, Mar 6, 2014 at 2:16 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2014-03-05 20:11 GMT+01:00 C. Scott Ananian ecmascr...@cscott.net:
On Wed, Mar 5,
I would rephrase into this:
if you need a getOwnPropertyNames trap, you might need for consistency a
getOwnPropertySymbols independently from getOwnPropertyDescriptors since
these methods are already available.
I also would like to add a couple of links to support the fact
That would not allow us to kill DOMStringList.
Can we get more background on DOMStringList? It seems unlikely that you could
get away with replacing a string-only type, which, from the specs I can find,
seems to be immutable and have an additional index() method, with an actual
mutable
I would rephrase into this:
if you need a getOwnPropertyNames trap, you might need for consistency a
getOwnPropertySymbols independently from getOwnPropertyDescriptors since
these methods are already available.
While it shares the same name with Object.getOwnPropertyNames(), this
André Bargull mailto:andre.barg...@udo.edu
March 6, 2014 at 1:21 PM
I would rephrase into this:
if you need a getOwnPropertyNames trap, you might need for consistency a
getOwnPropertySymbols independently from getOwnPropertyDescriptors since
these methods are already available.
While it
On 3/6/14 3:58 PM, Domenic Denicola wrote:
That would not allow us to kill DOMStringList.
Can we get more background on DOMStringList?
Sure. It's used in the following places in Gecko, as far as I can tell:
1) document.styleSheetSets.
2) Microdata API.
3) Various places in indexeddb.
4)
Thanks very much Boris. It sounds like there isn't much of a cross-browser or
standardized story on where `DOMStringList`, with its `contains()` and `item()`
methods (yeah, I meant `item`) shows up.
I'd be curious where it shows up in Blink, IE, and WebKit codebases. If the
intersection is
Boris Zbarsky wrote:
1) document.styleSheetSets.
2) Microdata API.
3) Various places in indexeddb.
4) The DataTransfer API.
5) Some sort of offline resource list API that's not part of any
standard I can find.
#1 is not implemented by anyone but Gecko, and the spec is claiming
it's a
On 3/6/14 4:49 PM, Brendan Eich wrote:
What's with all the no one implements (including #3) stuff in specs?
IDL Arrays in general are not implemented by anyone that I know of (and
possibly ever). They were a new concept added in WebIDL that hasn't
really caught on with implementations. In
Thanks Andrew, I wonder if I should update the proposed spec somehow, but I
thought as it is combines both Names and Symbols as abstract.
Please let me know and I'll update.
Best Regards
On Thu, Mar 6, 2014 at 1:21 PM, André Bargull andre.barg...@udo.edu wrote:
I would rephrase into this:
autocomplete misspelled Andre' , apologies
On Thu, Mar 6, 2014 at 2:34 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Thanks Andrew, I wonder if I should update the proposed spec somehow, but
I thought as it is combines both Names and Symbols as abstract.
Please let me know and
On 3/6/2014 10:24 PM, Brendan Eich wrote:
André Bargull mailto:andre.barg...@udo.edu
March 6, 2014 at 1:21 PM
I would rephrase into this:
if you need a getOwnPropertyNames trap, you might need for consistency a
getOwnPropertySymbols independently from getOwnPropertyDescriptors since
these
FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
Location.ancestorOrigins
On Thu, Mar 6, 2014 at 1:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 3/6/14 4:49 PM, Brendan Eich wrote:
What's with all the no one implements (including #3) stuff in specs?
IDL Arrays in
What exactly is being accomplished with tagged templates? I mean, what is
the use case? It seems to make certain specific function calls look very
different from a typical function call, the arguments passed in are not
very clearly explained in the draft or wiki, and I have difficulty
imagining
On 3/6/2014 11:35 PM, Andrea Giammarchi wrote:
autocomplete misspelled Andre' , apologies
No worries! :-)
On Thu, Mar 6, 2014 at 2:34 PM, Andrea Giammarchi
andrea.giammar...@gmail.com mailto:andrea.giammar...@gmail.com wrote:
Thanks Andrew, I wonder if I should update the proposed
– Regular expressions: https://gist.github.com/slevithan/4222600
– Escaping the variable parts of domain-specific languages
– HTML templates (think Facebook’s React)
– Internationalization
Axel
On Mar 7, 2014, at 0:29 , Caitlin Potter caitpotte...@gmail.com wrote:
What exactly is being
got it, thanks again.
On Thu, Mar 6, 2014 at 3:31 PM, André Bargull andre.barg...@udo.edu wrote:
On 3/6/2014 11:35 PM, Andrea Giammarchi wrote:
autocomplete misspelled Andre' , apologies
No worries! :-)
On Thu, Mar 6, 2014 at 2:34 PM, Andrea Giammarchi
andrea.giammar...@gmail.com
On Thu, Mar 6, 2014 at 6:31 PM, André Bargull andre.barg...@udo.edu wrote:
On 3/6/2014 11:35 PM, Andrea Giammarchi wrote:
The proposed [[GetOwnPropertyNames]] internal method is supposed to be a
more restrictive version of [[OwnPropertyKeys]] to ensure Proxy objects
don't lie about their
On the point of DLS's, are there any example points like the regex one you
posted Axel? I'm curious as to how you would do the transform
Subject: Re: Template strings and templates
From: a...@rauschma.de
Date: Fri, 7 Mar 2014 00:46:53 +0100
To: caitpotte...@gmail.com
CC: es-discuss@mozilla.org
Le 7 mars 2014 à 00:45, C. Scott Ananian ecmascr...@cscott.net a écrit :
And don't forget the related `DOMTokenList`, which is in
Element.classList and thus used by everyone always.
Indeed, and there is also the (less known) `htmlFor` property of the output
element, which is precisely a
How about:
```js
cs = require('coffee-script').compile;
eval(cs`
gcd = (x,y) - [x,y] = [y,x%y] until y is 0; x
`);
```
Presumably coffee-script counts as a (large!) DSL.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
Tagged template strings are one of my favorite parts of ES6. I include them and
generators in my [ES6 The Awesome Parts talk][1].
Sample uses from that slide deck, most of them cribbed from the wiki:
```js
// Contextual auto-escaping
qsa`.${className}`;
safehtml`a href=${url}?q=${query}
On Mar 6, 2014, at 15:46 , Axel Rauschmayer a...@rauschma.de wrote:
– Regular expressions: https://gist.github.com/slevithan/4222600
– Escaping the variable parts of domain-specific languages
– HTML templates (think Facebook’s React)
– Internationalization
Not internationalization. The
I'm sorry if that's been asked before (I looked trough the archives trough
to 2012 and couldn't find a thread on it).
Are there any plans on adding multiline strings?
Some examples of multiline strings below.
Lua:
foo = [[A
Multiline
String]]
Python:
foo = '''A
Multiline
String'''
We precisely discussed templates on es-discuss tonight. If I believe what I
just read on [1], you will be able to write:
foo = `A
Multiline
String`
—Claude
[1] http://www.slideshare.net/domenicdenicola/es6-the-awesome-parts/23
Le 7 mars 2014 à 08:21, Florian Bösch pya...@gmail.com a écrit :
// Localization and formatting
l10n`Hello ${name}; you are visitor number ${visitor}:n! You have ${money}:c
in your account!`
A correct German translation of this would have to take the gender of the
visitor into consideration:
Male: l10n`Hallo, Herr ${name}; Sie sind Besucher Nummer
28 matches
Mail list logo
