Awesome work! Truly an exciting milestone.
A lot of really nice stuff is in, and the future with ES7 looks bright.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Not sure why this is a reply to me - but I completely agree. All `class`
does is take an extremely common idiom and makes it simpler and easier to
get right with better defaults - it _is_ the same prototypical stuff. It's
an addition based on what people do and it's still entirely possible to do
Did you seriously just plug your blog post in es-discuss?
Are you really explaining the open-closed principle and composition vs
inheritance to a mailing list of people interested in language design?
About why class is added:
https://esdiscuss.org/topic/is-class-syntax-really-necessary
Well, if the user caches the result (in order to pass it to another
iterator) they'll get unexpected results.
Iterator A yields:
```js
{value: 1, done: false}
{value: 2, done: false}
{value: 3, done: false}
{value: 4, done: false}
```
There are two consumers for the iterator (sending the
From: Andrea Giammarchi andrea.giammar...@gmail.com
AFAIK bluebird did:
https://github.com/petkaantonov/bluebird
/blob/master/API.md#cancelerror-reason---promise
For what it's worth - bluebird is swapping its cancellation implementation
in a week or two. You can read about it here:
Why not? The generator would switch on sent value, in a loop.
Well, let's say we have an iterator that does nothing once, returns what
was sent to it the first 5 times and then is done:
```js
function* gen(){
var res = yield;
for(var i = 0; i 5; i++){
res = yield res;
}
}
var iter =
with promises is at least mildly cool).
That said I absolutely agree that more practical examples are required in
order to make this already way-powerful two way protocol into something
even more complicated.
On Mon, Feb 23, 2015 at 9:11 PM, Brendan Eich bren...@mozilla.org wrote:
Benjamin (Inglor
A programmer who wrote the assignment aPusher.push =
MyArray.prototype.push was probably thinking that they could just reuse the
push method from MyArray.prototype and that the super.push call within it
would start searching for a push method at the [[Prototype]] of aPusher.
But it doesn't.
As a
In my testing (and in my theory, as an absolute) this is a real
performance defect in the spec and it will make iterators inferior to
all other forms of sequence iteration, to the extent that they may end
up being used very rarely, and developers will be biased away from Map
and Set as a result.
On Sun, Feb 15, 2015 at 3:06 PM, Katelyn Gadd k...@luminance.org wrote:
In my testing Map and Set are outperformed by a trivial Object or
Array based data structure in every case, *despite the fact* that
using an Object as a Map requires the use of Object.keys() to be able
to sequentially
...@gmail.com wrote:
On Sun, Feb 15, 2015 at 7:16 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
This is something that can be solved at the VM level. VMs perform much
much smarter optimizations than this already. There is no reason to
sacrifice code correctness and the principle
Joe, I don't think we're having the same discussion.
Again, this is about the issue Katelyn raised about the return value of
`.next`.
Katelyn suggested that the return value of a `.next` call in the iteration
protocol - an object of the form `{value: value, done: boolean}` should be
allowed to
Looking at the syntax from here:
http://facebook.github.io/react/blog/2015/01/27/react-v0.13.0-beta-1.html#es7-property-initializers
ES7+ Property Initializers
Wait, assigning to properties seems like a very imperative way of defining
classes! You're right, however, we designed it this way
My questions is, how can we setup a function to abort a pending async
function?
That's an interesting question. Cancellation of promises is something
that has been debated several times (not sure if at all in esdiscuss).
There is a specification but there are many objections to it and some
Thanks, in case anyone is wondering this is the relevant result:
https://esdiscuss.org/topic/future-cancellation
On Tue, Feb 3, 2015 at 9:50 PM, Brendan Eich bren...@mozilla.org wrote:
Benjamin (Inglor) Gruenbaum wrote:
Cancellation of promises is something that has been debated several times
Hi, I recently answered a question on StackOverflow about set iteration
order which made me read the spec.
I remember the recent Set.prototype.entries: indices as keys discussion
but I couldn't figure out if the fact sets and maps are ordered on
insertion order is specified is intentional and an
used deterministic and tyler close
keywords to help.)
/be
Benjamin (Inglor) Gruenbaum wrote:
Hi, I recently answered a question on StackOverflow about set iteration
order which made me read the spec.
I remember the recent Set.prototype.entries: indices as keys discussion
but I couldn't
Bluebird is actually overhauling cancellation in 3.0 -
https://github.com/petkaantonov/bluebird/issues/415 for what it's worth
we're not agreeing about syntax or how to make it better either :)
For what little my opinion is worth here compared to the other people
involved I'm favouring the single
Yes, the non-overlapping way to write it IMO would be to isolate the
rejection on errors to a function:
```
let watchError = (client) = new Promise((resolve, reject) =
client.on(error, reject));
// as a plain promise
function fetchish(){
let client = new Client;
return
This looks sweet Domenic!
Especially things like
https://github.com/tc39/Array.prototype.includes/blob/master/README.md
It would be great it if were standardised and made more readable (the
sidebar for example)
On Mon, Feb 2, 2015 at 11:43 PM, Domenic Denicola d...@domenic.me wrote:
From:
- would people
use it?
On Mon, Feb 2, 2015 at 11:10 PM, Brendan Eich bren...@mozilla.org wrote:
Benjamin (Inglor) Gruenbaum wrote:
For example - I don't need to know or understand what `[[ReferenceGet]]`
is to understand something written in this sort of style:
https://wiki.php.net/rfc
Follow-up thought: people still link to the (completely outdated)
proposals on the wiki, because they are often very readable.
I think people mostly link to them because they are rank pretty well in
search results and are confined to a single problem in a readable way.
I think the way PHP
I think that people would generally will _expect_ `yield *` to be have like
yield inside a loop. So most people would expect:
```
yield* iterator
```
To behave like:
```
for(let val of iterator){
yield val;
}
```
While I'm not (yet) suggesting that the behaviour should be similar in both
Wirfs-Brock al...@wirfs-brock.com
wrote:
On Jan 31, 2015, at 10:13 AM, Benjamin (Inglor) Gruenbaum wrote:
I think that people would generally will _expect_ `yield *` to be have
like yield inside a loop. So most people would expect:
```
yield* iterator
```
To behave like
We'll probably talk about that tomorrow in a break-out. At least I hope
to!
Thanks, this sounds awesome. It's definitely one of the most awaited ES7
features and it's definitely highly applicable in a lot of code I'm writing
(and in a lot I'm reading).
If there is any help you guys need with
Hey, I know ES7 value types are not yet done and are definitely not ready
for prime time but I'd really like to play with them to get a hang of the
API.
I'll be working on a library that will likely take a while to build and
will greatly benefit from them and I want to think about the API.
Are
I'd just like to add that joke requests like Math.TAU that have no place
in the language specification itself generate a considerable amount of
overhead for those of us who keep up with the mailing list.
Especially since the other topics discussed are interesting (e.g.
ModuleImport ). I think it
I'd like to raise an issue with ES7 value objects with maps raised here:
http://esdiscuss.org/topic/maps-with-object-keys
To save you all time, let me sum things up:
ES6 maps don't solve a particular (but common) issue for me - using
compound objects as keys. I do a lot of statistical analysis
I'm trying to work with ES6 Map objects and I ran into an interesting
problem.
I want to index/group based on several key values. Let's say my original
data is something like:
```js
[{x:3,y:5,z:3},{x:3,y:4,z:4},{x:3,y:4,z:7},{x:3,y:1,z:1},{x:3,y:5,z:4}]
```
I want to group it based on the x
function for tuple like objects would be more clear
than comprehension that does not relate to the mapping of key to value.
Notice how the keys of `map` are never used in the comprehension.
On Mon, Feb 17, 2014 at 3:35 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Hi, when you reply
Orendorff
jason.orendo...@gmail.comwrote:
On Mon, Feb 17, 2014 at 3:09 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
I'm trying to work with ES6 Map objects and I ran into an interesting
problem.
Yes! Well done.
We've noticed this too, and considered (a) allowing objects
When you asked about discussion and this ran into my mind :)
I remember it was discussed here
http://esdiscuss.org/topic/protocol-library-as-alternative-to-refinements-russell-leggett,
( the syntax in
https://gist.github.com/genericallyloud/7086380 )
Do the semantics proposed above work with
I'm new too, but don't think that's exactly how things get proposed here :)
Spec changes don't start with solutions - they start with existing problems
you're trying to solve. For example. In ES6 I might do
```js
var res = ({
hello : () = 12, /* no fallback */
world : () = 323, /* no
On Sat, Feb 8, 2014 at 2:57 PM, Quildreen Motta quildr...@gmail.com wrote:
Well, promises are a fairly old concept, with several different
implementations throughout the history of CompSci, and even in JavaScript
land itself. `.chain` itself is not common because it doesn't need to have
Thanks, this clarifies things. I'll update the answer on SO to reflect the
findings.
On Thu, Jan 9, 2014 at 3:54 AM, André Bargull andre.barg...@udo.edu wrote:
Thanks for the reply.
I'd actually expect `undefined` because function declarations does not
return anything. Converting it to a
I've recently run into this question in Stack Overflow:
http://stackoverflow.com/q/21008329/1348195
```
function f() {
f = eval( + f);
console.log(Inside a call to f(), f is: \n%s, f);}
f();
console.log(After a call to f(), f is: \n%s, f);
```
What should the output of the following
On Wed, Jan 8, 2014 at 3:37 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
I've recently run into this question in Stack Overflow:
http://stackoverflow.com/q/21008329/1348195
```
function f() {
f = eval( + f);
console.log(Inside a call to f(), f is: \n%s, f);}
f
From: Shijun He hax@gmail.com
Subject: Re: About Array.of()
This is an old thread which I like to mention again. The proposal is
change the method name from Array.of() to Array.fromElements() to make it
clear especially for non-English native programmers.
`Array.of` sounds a lot more
Array.of sounds expressive only for native speakers.
English is not my first language and it sounded expressive to me. I've
asked 5 random friends that code and they all said it sounded fine to them.
While that's not real evidence, it still shows that the only doesn't hold
here.
The only valid
18, 2013 at 11:16 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
May I ask what String.prototype.contains accomplish with a regular
expression (that we don't already have with `RegExp.test`)?
Consistency with the other methods, maybe? It would be bad API design
to insist on there's
How would you define Array.isArray on the Array prototype? That'd just fail
for everything that is not an array and doesn't implement isArray itself.
Things like Object.keys are reflective, enumerating over the properties of
an object (even more so in ES6) is not something you'd commonly do in
Here's how I see this post:
- Performing Evented I/O well is one of the biggest use cases of
JavaScript - in the browser, in mobile apps, on the server and generally.
- Exceptions in I/O scenarios did not traditionally post a problem
since constructs like callbacks and promises were used.
rossb...@google.comwrote:
On 21 November 2013 01:55, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum wrote:
You tell me I don't need to sell you this - who do I need to sell this
to?
What people do I convince in order to have better catch clauses that
solve
my
for a failed guard is
different in the try/catch scenario than with parameters or properties.
[1] http://wiki.ecmascript.org/doku.php?id=strawman:guards
On Wed, Nov 20, 2013 at 10:24 AM, Brendan Eich bren...@mozilla.comwrote:
Benjamin (Inglor) Gruenbaum wrote:
Hi, thanks for the comment
Honestly I'm really not sure how I feel about this.
Guards are a huge deal. They're a big (and nice!) feature, it sounds like
they bring a lot of complexity (specifying them, not using then). They'll
likely require a lot of work and debate in order to make it in (or not).
I have a very real and
Hi, I was wondering where I could get an up-to-date list of TC39 members. I
know of http://tc39wiki.calculist.org/about/people/ but I'm not sure it is
up to date.
Thanks,
Benjamin
___
es-discuss mailing list
es-discuss@mozilla.org
Any form of reply on this question/problem would be highly appreciated. I
believe this is a real use case and I'd like to know what other people
think.
I've had to deal with this multiple times since I sent this to es-discuss.
On Tue, Nov 5, 2013 at 5:39 PM, Benjamin (Inglor) Gruenbaum
ing
please let me know and
I'll try to add a clearer sample.
Thanks,
Benjamin
On Wed, Nov 20, 2013 at 1:03 AM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum wrote:
Any form of reply on this question/problem would be highly appreciated. I
believe this is a real use case and I'd
From: Allen Wirfs-Brock al...@wirfs-brock.com
One of the the few remaining uses of a function's 'arguments' binding is
to determine the actual number of passed arguments. This is necessary in
some overloading scenarios where a function has different behavior when an
argument is completely absent
Traditionally, JavaScript code contains some sort of asynchronous logic
either on the client side or on the server side.
This makes the `try/catch` construct non-practical for many real use cases
because it can not catch errors caused by callbacks and/or other
asynchronous operations involved.
understand why you wouldn't phrase the problem entirely in terms of
synchronous operations since nothing seems unique to async.
On 5 Nov 2013, at 09:48, Benjamin (Inglor) Gruenbaum ing...@gmail.com
wrote:
Traditionally, JavaScript code contains some sort of asynchronous logic
either
Russell, thanks for the reply, it clarified a lot. I just wanted to mention
that I did not bring up C# extension methods to suggest this behavior for
protocols but just to illustrate how a different system for addressing a
similar problem (in a different environment) does it. I do not think
Dean Landolt d...@deanlandolt.com wrote:
Say you have an object for which you want to implement the Cowboy and
Canvas protocols (to borrow /be's favorite example). Both implement a
draw method, but when you try to import from both protocols you'll
naturally have to rename one or both. Now say you
On Tue, Oct 22, 2013 at 8:10 PM, Russell Leggett russell.legg...@gmail.com
wrote:
Revised algorithm:
1. If receiver has protocol method symbol as a property, use that as
override.
2. Try to use protocol methods - start by checking receiver type mapping,
then check up type hierarchy for any
it gave me a pretty good indication.
Thanks a lot for this discussion, I've learned a lot. Sorry if I wasted
someone's time.
Benjamin Gruenbaum.
On Wed, Oct 16, 2013 at 1:04 AM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15, 2013 2:00 PM
Russell Leggett russell.legg...@gmail.com wrote:
https://gist.github.com/genericallyloud/7086380
Very interesting.
// 4. use the default if available
what's the default in #4? The protocol's default? What's the behavior if
no matching method is found?
Also, can anyone explain why this
a
method `Foo` at the same specificity level - what happens?
Thanks
On Mon, Oct 21, 2013 at 10:35 PM, Russell Leggett russell.legg...@gmail.com
wrote:
On Mon, Oct 21, 2013 at 3:17 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Russell Leggett russell.legg...@gmail.com wrote
I don't think that's the same thing at all.
Detecting an infinite loop is _extremely_ hard at most cases (and of course
impossible at others. However instead of discussing the halting problem, I
think what's bothering this guy is that `.then` does not throw an error
when an error occurs within it
On Tue, Oct 22, 2013 at 12:15 AM, Russell Leggett russell.legg...@gmail.com
wrote:
I'll preface this by saying that I haven't made a formal proposal and
this isn't an actual library. You're doing a good job of spotting some
undefined behavior which would probably be better defined by trying it
I also noticed the naming similarity to ES6 `Symbol`s.
I've seen people fill `String.prototype.getFullChar` before and similarly
things like `String.prototype.fromFullCharCode` for dealing with surrogates
before. I like `String.prototype.signAt` but I haven't seen it used before.
I'm eager to
Splitting by one value or another seems to be a pretty common use case if
Stack Overflow questions and personal experience are an indication. For
example - and and /.
Currently, the solution is to pass a regular expression to
String.prototype.split .
However, it would be nice to be able to
(Inglor) Gruenbaum
ing...@gmail.com wrote:
Splitting by one value or another seems to be a pretty common use case if
Stack Overflow questions and personal experience are an indication. For
example - and and /.
Currently, the solution is to pass a regular expression to
String.prototype.split
Giammarchi
andrea.giammar...@gmail.com wrote:
I stopped here
On Wed, Oct 16, 2013 at 5:54 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
```
myString.split(/ |-|\/|\+/g); // this is no fun to read
myString.split( ,-,/,+); // this is easier
myString.split
On Wed, Oct 16, 2013 at 9:03 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
How could change 12+ years of legacy be considered inexpensive ?
This proposal does not break anything, the only thing that will/might work
differently is people passing an array to .split right now and
), usually I just suggest a
literal in the cases they do :) Thanks for the tip though, I should really
read the ES6 current spec from start to end.
On Wed, Oct 16, 2013 at 11:46 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Wed, Oct 16, 2013 at 4:25 PM, Benjamin (Inglor) Gruenbaum
ing
that if we can get away with
it it's totally worth it :)
On Mon, Oct 14, 2013 at 11:14 PM, Brendan Eich bren...@mozilla.com wrote:
Definitely deep waters here, not one simple thing. Appreciate your
interactions.
Benjamin (Inglor) Gruenbaum wrote:
But there were design issues too. ... user
thing to teach every programmer learning the language JavaScript and an
extra bit of cognitive overload.
On Tue, Oct 15, 2013 at 12:50 PM, Andreas Rossberg rossb...@google.comwrote:
On 14 October 2013 22:10, Benjamin (Inglor) Gruenbaum ing...@gmail.com
wrote:
But there were design issues too
, Russell Leggett
russell.legg...@gmail.comwrote:
On Tue, Oct 15, 2013 at 3:45 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Brendan Eich bren...@mozilla.com wrote:
We already have good motivation for :: anyway, as sugar for bind. This
gives relief to the OO side of the expression
Wait, I think maybe I did not understand what you meant before.
Are we talking about using `::` for infixing the first parameter of the
function? As in `func(a,b,c)` being the same as `a::func(b,c)` ?
Would that let us do `[1,2,3,4,5]::_.reduce(x=x%2 ===
0)::_.map(x=2*x)::._.reduce(x,y) =
-
that function gets called. If I had an extension method on Cat.prototype,
I'd get the correct behavior for kitten who overrides that method on
its prototype.
On Tue, Oct 15, 2013 at 8:26 PM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15
for the wiki page.
On Wed, Oct 16, 2013 at 12:00 AM, Russell Leggett russell.legg...@gmail.com
wrote:
On Tue, Oct 15, 2013 at 4:28 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Wait, I think maybe I did not understand what you meant before.
Are we talking about using `::` for infixing
Not resolving this like o3 (or o6 really) sounds very strange. I think:
let attr = __proto__;
let o7 = new Object;
o7[attr] = p; // o7 inherits from p
Is the correct behavior here (why would it not invoke the setter?)
On Wed, Oct 16, 2013 at 12:04 AM, Dean Landolt d...@deanlandolt.com wrote:
, 2013 at 1:04 AM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 15, 2013 2:00 PM
I think I misunderstood `::` before. if `a::b(x_1,...,x_n)` _just_ means
`b(a,x_1,...,x_n)`
No, rather: `b.call(a, x_1, ..., x_n)` but with the original
On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich bren...@mozilla.com wrote:
So, see the
http://scg.unibe.ch/archive/**papers/Berg03aClassboxes.pdfhttp://scg.unibe.ch/archive/papers/Berg03aClassboxes.pdf
work,
which inspired Ruby refinements as well as the scoped object extensions
strawman, and
Let me start by apologizing for adding noise to the list.
I looked for discussion of the standardization of __proto__ in the ES6 spec
and couldn't find any. This is probably my shortcoming but I didn't know
where to look or how to search the mailing list.
I found a lot of threads discussing
...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 14, 2013 12:37 PM
On Mon, Oct 14, 2013 at 6:44 PM, Brendan Eich bren...@mozilla.commailto:
bren...@mozilla.com wrote:
So, see the
http://scg.unibe.ch/archive/**papers/Berg03aClassboxes.pdfhttp://scg.unibe.ch/archive
them here to avoid just saying do your
own search, but I'm short on time, sorry!
/be
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 14, 2013 12:51 PM
Let me start by apologizing for adding noise to the list.
I looked for discussion of the standardization of __proto__ in the ES6
,
Andrea Giammarchi
On Mon, Oct 14, 2013 at 12:51 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Let me start by apologizing for adding noise to the list.
I looked for discussion of the standardization of __proto__ in the ES6
spec and couldn't find any. This is probably my
Scoped binding of a method to an object
Well, I know how some languages solve this issue but I wondered if
ECMAScript considered addressing this or already have and I missed it.
Often, I want to extend objects, for example -
Array.prototype.shuffle - takes an array and shuffles it.
However,
.
On Sun, Oct 13, 2013 at 9:25 PM, David Bruant bruan...@gmail.com wrote:
Le 13/10/2013 20:03, Benjamin (Inglor) Gruenbaum a écrit :
David Bruant bruan...@gmail.com wrote:
Concretely, attempted prolyfills, could be _-prefixed (that really
fits with what you call poor-man's
and get a
better understanding of the challenges something like this would bring.
On Sun, Oct 13, 2013 at 9:37 PM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 13, 2013 11:00 AM
Brendan Eichbren...@mozilla.com mailto:bren...@mozilla.com
to waste your time)
On Sun, Oct 13, 2013 at 10:00 PM, Mark S. Miller erig...@google.com wrote:
On Sun, Oct 13, 2013 at 11:36 AM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
First of all - well put.
Thanks.
Second, wouldn't being able to do this in a scoped way solve the conflict
.
On Sun, Oct 13, 2013 at 10:15 PM, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 13, 2013 11:19 AM
Keeping a third parameter beyond object and property name seems
unnecessary.
Here is a counterexample based on the strawman's syntax
responsibility and making decisions.
Peter
On Sun, Oct 13, 2013 at 8:47 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Prollyfilling is great too (perhaps you disagree?), and as its name
suggests it happens *before* the method is added to the spec.
So in your opinion adding
at 11:53 PM, Rick Waldron waldron.r...@gmail.comwrote:
On Sun, Oct 13, 2013 at 2:00 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Brendan Eich bren...@mozilla.com wrote:
No, object detection, polyfilling, and even prollyfilling are common
and successful adaptationsp on the Web
, Brendan Eich bren...@mozilla.com wrote:
Benjamin (Inglor) Gruenbaum mailto:ing...@gmail.com
October 13, 2013 2:28 PM
Thanks, this really helped me understand the underlying issue here
forcing dynamic resolution of scope here. It sounds a lot harder than I
initially thought
I have to say
There are two things here:
- In JS I (as well as most code in libraries I read) tend to use function
expressions a lot. The arrow notation is easier to read in my opinion. It's
shorter and more concise. That's a weak argument for it, but I think just
making the language more concise is an
I just asked Raul's weird syntax question in SO and tried to answer it
myself. Going through the spec, I have to admit that he has a point and
things could be clearer. I think the JS spec being good is a big factor not
only for implementers but for developers too and it could be better :)
, Benjamin (Inglor) Gruenbaum wrote:
I just asked Raul's weird syntax question in SO and tried to answer it
myself. Going through the spec, I have to admit that he has a point and
things could be clearer. I think the JS spec being good is a big factor not
only for implementers but for developers
89 matches
Mail list logo
