Ah, oh yes. I think I fail at mailing lists :3
2011/7/1 Peter Michaux petermich...@gmail.com
Did you mean to send this to es-discuss?
Peter
On 2011-07-01, at 8:51 AM, Quildreen Motta quildr...@gmail.com wrote:
Actually, in my opinion, constructor functions add needless complexity
2011/9/29 Peter van der Zee e...@qfox.nl
On Thu, Sep 29, 2011 at 3:43 AM, Quildreen Motta quildr...@gmail.com
wrote:
I'm not sure how this is much different from the rules you have now with
ASI, though if this were such a problem, a block statement could be
required
I'm trying to make
On 03/10/11 19:49, Erik Arvidsson wrote:
On Mon, Oct 3, 2011 at 14:50, Axel Rauschmayera...@rauschma.de wrote:
It’s a performance thing support for dynamic super would slow everything
down and is thus not worth it. In the current spec, there is a method for
moving methods with super from one
On 03/10/11 20:44, Axel Rauschmayer wrote:
super being rare and moving methods being rarer, I think the tradeoff
for performance is OK, especially as there will be a method that
allows you to move methods. If performance wasn’t an issue, dynamic
super would be preferable.
Hm, I wouldn't
On 05/10/11 22:05, Brendan Eich wrote:
On Oct 4, 2011, at 7:19 AM, Juan Ignacio Dopazo wrote:
Yes, tools should be better, but they need to start becoming better
by themselves as previous discussions here have noted.
However, there are problems in the language that need to be addressed
by
On 05/10/11 23:06, Brendan Eich wrote:
On Oct 5, 2011, at 7:01 PM, Quildreen Motta wrote:
On 05/10/11 22:05, Brendan Eich wrote:
On Oct 4, 2011, at 7:19 AM, Juan Ignacio Dopazo wrote:
Yes, tools should be better, but they need to start becoming better by
themselves as previous discussions
On 06/10/11 00:02, Juan Ignacio Dopazo wrote:
On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten rayn...@gmail.com
mailto:rayn...@gmail.com wrote:
Object.create does indeed require propertydescriptors as the
second argument. This is the easiest way to send meta-data like
read-only.
2011/10/6 John J Barton johnjbar...@johnjbarton.com
On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich bren...@mozilla.com wrote:
On Oct 5, 2011, at 9:02 PM, John J Barton wrote:
PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(),
hasOwnProperty was in ES3 in 1999.
On 06/10/11 19:56, John J Barton wrote:
Recent syntax discussions head in a completely different direction,
introducing a seemingly large number of new symbols resulting in code
that isn't readable by current JS, Java, or C devs. Instead of
JavaScript they will be attempting to read
2011/10/7 John-David Dalton john.david.dal...@gmail.com
As for the functionality, it should just be an n-ary function which
extends
the first object with all the _own_ properties of the other n-1 objects.
If
keys clash give right precedence.
I've used this flavor of extends too (minus
2011/10/7 John J Barton johnjbar...@johnjbarton.com
On Fri, Oct 7, 2011 at 8:34 AM, Axel Rauschmayer a...@rauschma.de wrote:
If you do something like
var fuz = Object.extend(foo, {paper:'in', shoes:'my'});
Then fuz will get all properties of Object.prototype, again, as
duplicates.
2011/10/7 John J Barton johnjbar...@johnjbarton.com
On Fri, Oct 7, 2011 at 9:16 AM, Quildreen Motta quildr...@gmail.comwrote:
2011/10/7 John J Barton johnjbar...@johnjbarton.com
On Fri, Oct 7, 2011 at 8:34 AM, Axel Rauschmayer a...@rauschma.dewrote:
If you do something like
var
We already get factory constructors by default -- by returning an object
from the constructor function.
2011/10/10 Axel Rauschmayer a...@rauschma.de
In many ways, Dart feels *less* versatile than ECMAScript.next. However,
there are two ideas that would make a nice addition to class literals:
? But it shouldn’t
be hard to let a compiler perform that kind of optimization.
On Oct 10, 2011, at 13:58 , Quildreen Motta wrote:
We already get factory constructors by default -- by returning an object
from the constructor function.
2011/10/10 Axel Rauschmayer a...@rauschma.de
In many ways, Dart
2011/10/13 Russell Leggett russell.legg...@gmail.com
On Thu, Oct 13, 2011 at 12:46 PM, Douglas Crockford doug...@crockford.com
wrote:
On 11:59 AM, Brendan Eich wrote:
CoffeeScript users have to know JS semantics, even if they don't think of
it that way.
Syntax was the point, though,
Contracts would be interesting, but perhaps too expensive?
fib :: (Number) - Number
function fib(n) {
return n == 0? 0
: n == 1? 1
: fib(n - 1) + fib(n - 2)
}
or function fib(n Number) - Number { }
Not particularly proposing any syntax though. Not particularly
This is the whole reason I love Scheme :3
2011/10/13 Claus Reinke claus.rei...@talk21.com
But I am doubtful that that lightness results in better productivity.
Typing is not where we spend the bulk of our time.
Good language designs tend to have light syntax (but not all light syntax
2011/10/13 Brendan Eich bren...@mozilla.com
On Oct 13, 2011, at 3:29 PM, Kris Kowal wrote:
Your proposal resembles Waldemar’s guards and trademarks.
http://wiki.ecmascript.org/doku.php?id=strawman:trademarks
http://wiki.ecmascript.org/doku.php?id=strawman:guards
You might consider
2011/10/14 Peter Dekkers pe...@jbaron.com
Some of the advantages I could see:
1. JsDoc becomes a standard part of Language. This has to be a good
thing even without using it is as basis for stronger typing: a
uniform way of documenting code.
I fail to see why One True Way for everything
2011/10/14 Brendan Eich bren...@mozilla.com
On Oct 14, 2011, at 9:25 AM, Quildreen Motta wrote:
I think my major pet-peeve against using strict types for contracts is:
1.) JS is not a statically typed language, it's an overtly dynamic
language with prototypical OO. Using it as the former
2011/10/14 Jake Verbaten rayn...@gmail.com
On Fri, Oct 14, 2011 at 2:44 PM, Peter Dekkers pe...@jbaron.com wrote:
I think the entire proposal based on auto generating gaurds from
documentation is not that useful. It forces you into a type of
documentation. I want to choose my
2011/10/14 Peter Dekkers pe...@jbaron.com
I checked the strawman and it looks nice. However the introduction of
something like :: would surely not run on older VM's that don't
understand that construct. Is that not a perceived problem more in
general: adding a nice new language constructs
On 15/10/11 11:47, Jake Verbaten wrote:
Im suggesting the rule is value of this binds at location of function
instantation.
I would expect an invocation of the function elsewhere to still have
the this value of the other function (o1 not o2).
As long as people understand and follow the
On 29/10/11 21:03, Axel Rauschmayer wrote:
There are two things is JavaScript that are simple and elegant and
universally liked:
- Prototypes
- Object literals
How come we can’t transport that simplicity to classes? Once the
objects have been created, we are happy with them, but how to best
On 30/10/11 01:07, Axel Rauschmayer wrote:
Now, for the past few months, I've been defining my objects like this:
// where `clone' = Object.extend(Object.create(proto), props)
var Thing = function(){ return (
{ clone: _clone
, toString: toString
})
function clone(name){ return clone(Thing, {
On 30/10/11 09:45, Rick Waldron wrote:
On Oct 30, 2011, at 5:58 AM, David Bruantbruan...@gmail.com wrote:
Le 30/10/2011 02:35, Quildreen Motta a écrit :
(...)
Are we overthinking classes?
Perhaps the reason for all this thinking about classes come from the
role constructor functions take
I still think | is more straight-forward to grasp to non-native speakers
-- they're likely to have stumbled upon that on UML classes, methinks.
Also, there's the problem of creating new reserved words in the languages,
imho it makes a language feel heavier and clunkier. I think one of the
greatest
While the class literal proposed by Jeremy is indeed nice, I think it
misses the point of *why* class literals are desirable. What you've
proposed can already be achieved, with the same sugar -- and without
introducing a new construct, so people using ES3 can also get it through a
library, etc --
On 01/11/11 22:18, Brendan Eich wrote:
On Oct 31, 2011, at 6:57 PM, Jeremy Ashkenas wrote:
'Evening, ES-Discuss.
After poking a stick in the bees' nest this morning (apologies,
Allen), and in the spirit of loyal opposition, it's only fair that I
throw my hat in the ring.
Here is a
On 02/11/11 00:01, Brendan Eich wrote:
On Nov 1, 2011, at 6:57 PM, Quildreen Motta wrote:
I like how clean the syntax is there, Brendan. I still feel class syntax would
have more value if they presented a nice way for object composition besides
inheritance.
Traits were factored out and I
On 02/11/11 11:01, Erik Corry wrote:
2011/11/2 Axel Rauschmayera...@rauschma.de:
super Foo.bar(x) should desugar to Foo.prototype.bar.call(this, x)
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super
What is that you don’t like about Allen’s proposal? You are still
On 02/11/11 13:01, David Bruant wrote:
Le 02/11/2011 14:26, Jeremy Ashkenas a écrit :
(Full Disclosure: I'm still very opposed to const, private, and their
object-lockdown friends, )
Regarding const, it's an optional keyword basically telling the
interpreter hey, the value isn't suppose
On 02/11/11 14:05, Jeremy Ashkenas wrote:
On Wed, Nov 2, 2011 at 11:01 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Could you elaborate on this point?
All object-lockdown I can think (non-configurability,
non-writability, non-enumerability, private names,
On 02/11/11 14:26, John J Barton wrote:
Another maybe stronger argument is simplicity: these myriad new minor
features create a blizzard of chaff in the way of developers. One
excellent example is Object.create(). Here was a terrific opportunity
to simplify the language based on years of
On 02/11/11 15:41, Brendan Eich wrote:
On Nov 2, 2011, at 9:26 AM, John J Barton wrote:
Of course these details are
important for the use-cases that need them. Unfortunately everyone
else has to carry the baggage.
What exactly do you mean by carry?
Implementors have to implement. They get
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account that functions in JavaScript are not bound
to an object, they are generic. You can simply assign any
On 02/11/11 15:49, Brendan Eich wrote:
On Nov 2, 2011, at 9:30 AM, Quildreen Motta wrote:
Also, note that `with' makes a whole awesome use-case for `Object.freeze':
'with' is gone in ES5 strict, ES6, and beyond -- you knew that, right?
Yep, and I still think it's a sad thing. Not that I use
On 02/11/11 16:21, Brendan Eich wrote:
On Nov 2, 2011, at 10:52 AM, Quildreen Motta wrote:
On 02/11/11 15:42, Erik Corry wrote:
2011/11/2 Quildreen Mottaquildr...@gmail.com:
I don't think hard coding the name of the super-constructor is a
problem.
It is when you take into account
I think Claus summarizes nicely what I've been thinking about this thread,
and the opposition-for-the-sake-of-opposition that has been spreading
through the JavaScript community. Though most of that seems to be based on
JavaScript should be kept simple. I'd argue there doesn't need to be
conflicts
On 08/11/11 18:49, Brendan Eich wrote:
The recommended practice when writing for-in loops in JS today is to
write:
for (i in o) {
if (o.hasOwnProperty(i)) {
/body/
}
}
Although many JS developers do not follow the recommendation (out of
ignorance or intentionally, doesn't
On 08/11/11 19:19, Axel Rauschmayer wrote:
I see two domains for the concept of “own” properties:
1. Meta-programming.
Could you expand on the use of `own' properties for meta-programming?
I'm afraid I can't really envision it =/
2. Using objects as dictionaries.
Isn’t #2 the majority (at
On 08/11/11 20:22, Axel Rauschmayer wrote:
I see two domains for the concept of “own” properties:
1. Meta-programming.
Could you expand on the use of `own' properties for meta-programming?
I'm afraid I can't really envision it =/
Whenever you copy properties from one object to another one,
On 08/11/11 21:36, Brendan Eich wrote:
Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach.
How many run into the wrong |this| (arguments/break/continue/return)? Not
clear. Something to study.
Well, I use Object.keys, etc, a lot thorough my code. I can't remember a
On 08/11/11 23:59, Jake Verbaten wrote:
However on average a lot more people will use for ... in with
hasOwnProperty because ES5 environments are rare and a lot of people
avoid the ES5-shim
Do you mean `rare' as in they have to work with the lowest common
denominator (IE)? Because
2011/11/9 John J Barton johnjbar...@johnjbarton.com
I'm sure this has been discussed before, but isn't is possible and
desirable to make |this| illegal in using strict; when it can be
determined from the AST alone that |this| will bind to |window|? eg:
On 11/11/11 23:44, John J Barton wrote:
On Fri, Nov 11, 2011 at 4:48 PM, Brendan Eichbren...@mozilla.com wrote:
On Nov 11, 2011, at 4:42 PM, John J Barton wrote:
Object.extend() does not exist.
Which one do you mean?
I mean Object.extend does not exist.
Irakli is using
On 12/11/11 19:07, John J Barton wrote:
This kind of discussion illustrates my point: JS is not sweet enough
because we are missing core operations for constructing prototypes in
a standard way.
Agreed. I've always thought about JS objects as sets, but it feels weird
that I don't get
On 19/11/11 13:42, Axel Rauschmayer wrote:
(I'm thinking about blog posts here, which typically face the dilemma
of talking about [[prototype]] vs 'prototype', to help
readers in the long run while confusing them at first, or talking
about __proto__, to be understood in the short run, with
2011/11/22 Bob Nystrom rnyst...@google.com
On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich bren...@mozilla.comwrote:
Nothing there about arrays or regular expressions, and the function
examples do *not* show anything like
superFun | function (...) {...}
Instead of Ahem'ing, could you
I have an obvious bias towards 1 because I think Unicode symbols
describe much better the underlying intentions and semantics than
their ASCII alternatives (usually), however not many people creates
mappings for these symbols on their .XCompose (or even have a compose
key handy).
I remember you
I find the syntax `proto - object' counter-intuitive. Anytime I think
about prototype delegation,
the semantics are clear that an object `X' delegates to a prototype `Y'.
This semantics don't map
well in `proto - object', instead you have something more along the
lines `proto is the basis of
I find the syntax `proto - object' counter-intuitive. Anytime I think
about prototype delegation,
the semantics are clear that an object `X' delegates to a prototype `Y'.
This semantics don't map
well in `proto - object', instead you have something more along the
lines `proto is the basis of
On 03/04/2012 02:14 PM, Allen Wirfs-Brock wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Dean Landolt wrote:
Does it /have/ to be ascii?
Does it have to be grawlix? [snip...]
I have two significant sized code samples that differ only in the use
of beget in place of |
Compare:
On 03/04/2012 03:38 PM, Gavin Barraclough wrote:
On Mar 3, 2012, at 11:17 PM, Brendan Eich wrote:
Does it have to be grawlix? I proposed
let sub = sup beget {p:1, q:2, r:3};
+1. Using a symbol like an arrow makes a lot of sense when there is a
clear directionality in the operation (e.g.
On 03/17/2012 01:55 PM, François REMY wrote:
Wouldn't it be better to use 'as' for guards? Seems more intuitive and
easier to type
let A as Number = 3;
let B as Email = x...@google.com;
class ListNode {
public nextNode as ListNode;
public value; // no guard
}
On 01/04/12 18:49, Peter van der Zee wrote:
No idea whether this has been discussed before, but I find myself
continuously doing this when sorting arrays with objects:
arr.sort(function(a,b){ if (a.prop b.prop) return -1; if (a.prop
b.prop) return 1; return 0; });
Couldn't we add an optional
On 01/04/12 15:08, Allen Wirfs-Brock wrote:
On Apr 1, 2012, at 8:07 AM, Quildreen Motta wrote:
How is the above better (ignoring any controversy about line-beginning
separators) than:
let ps = {
lookahead ( n) { this.current().slice(0, n || 1) },
current() { this.text.slice
I'm still amazed to see people rant about other people's perfectly fine
coding styles, when those are an overtly subjective matter, and therefore
no argumentation on whether Yes ASI or Nay ASI can be right.
The only facts about ASI are:
1.) It's a syntax error;
2.) Such syntax error is spec'd to
On 22 April 2013 09:18, Andreas Rossberg rossb...@google.com wrote:
On 21 April 2013 04:15, David Herman dher...@mozilla.com wrote:
On Apr 20, 2013, at 5:17 AM, Brendan Eich bren...@mozilla.com wrote:
Moreover, ad-hoc seems to suggest some sort of arbitrariness, as if
it's not
Andreas is suggesting we adopt a convention or design pattern for
anonymous exports. Dave is suggesting that it should be supported at the
syntax level, so you get language-level guarantees rather than wishful
thinking.
On 22 April 2013 11:24, Axel Rauschmayer a...@rauschma.de wrote:
Andreas
On 23 April 2013 09:34, Andreas Rossberg rossb...@google.com wrote:
On 22 April 2013 17:03, Brendan Eich bren...@mozilla.com wrote:
The more convincing argument would be interop with those legacy
modules. But the magic for that will be in custom loaders, and AFAICS,
the problems (and
On 1 June 2013 20:52, Jorge jo...@jorgechamorro.com wrote:
On 02/06/2013, at 01:22, Brandon Benvie wrote:
On 6/1/2013 3:44 PM, Jorge wrote:
{
block: {
if (true) {
break block;
}
}
}
But then... I'm not sure this is any better than an IIFE!
Anything is better than
One company I advise tried it, and found that its unsyntax bit back in
this way: code that compiled and seemed to do one thing did something quite
different. This happens with JS due to ASI; it also happens just due to the
C syntax heritage. But it happens more often with CoffeeScript, from
In principle, with functions-as-collections the yield and the whole
generators stuff
is not needed. If functions can be used on the right of 'in' or 'of'
in 'for' then
all 'yield' use cases that I saw so far can be implemented without the
yield.
So why do we need redundant entities?
Ressurrecting this thread whoo :)
I don't feel static typing making its way to JavaScript. It just wouldn't
fit. The core libraries haven't been designed for it, and the community
libraries haven't been designated for it. I'd say static typing in JS is a
lost cause now. Designing a language for
The idea of having shared mutable state in a language is a horrifying one.
I'm glad JavaScript isn't heading in that direction.
We *do not* need threads for parallelism, and scaling in to use multiple
cores. In Browsers, we can already have isolated parallelism through
WebWorkers, which means
Ah, this looks really neat! :D
I wasn't familiar with any research on formalising JavaScript semantics
besides λjs, so it's neat to see more research on this front :)
On 25 January 2014 22:55, Gareth Smith g...@doc.ic.ac.uk wrote:
Apologies if this is a duplicate - I tried sending this
So, if I understand correctly, it basically boils down to:
Promise.resolve :: a → Promise(a)
Promise.cast :: a → Promise(a)
Promise.cast :: Promise(a) → Promise(a)
But right now we'll only get `.then`, so transformations with nested
promises will flatMap automatically:
Promise.then ::
On 28 January 2014 21:27, Andreas Rossberg rossb...@google.com wrote:
On 28 January 2014 21:21, Quildreen Motta quildr...@gmail.com wrote:
But later, once `flatMap` is introduced, you'll be able to deal with
nested
promises without breaking parametricity:
Promise.flatMap :: (Promise
On 29 January 2014 01:27, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote:
On Tue, Jan 28, 2014 at 7:47 PM, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
Seriously, Haskell calls it=.
Right, that thing. Did it have the f-l-a-t-... name in Haskell, or is it
On 29 January 2014 10:45, Paolo Amadini paolo.02@amadzone.org wrote:
On 29/01/2014 5.12, Kris Kowal wrote:
In this case, a half pursuit of type purity is a side quest at the
expense of users. Having two ways to resolve and two ways to observe a
promise is unnecessarily confusing. In my
I can understand the you can't have your cake and eat it too sentiment.
Indeed, I do think that having `.then()` and `.chain()` in the spec is a
mistake. The only thing that saddens me (and this also with some other
parts of the spec, such as Object.create) is that `.then()` is not an
orthogonal
On 8 February 2014 07:37, Benjamin (Inglor) Gruenbaum ing...@gmail.comwrote:
-- Forwarded message --
From: Brendan Eich bren...@mozilla.com
To: Kevin Smith zenpars...@gmail.com
Cc: Mark S. Miller erig...@google.com, EcmaScript
es-discuss@mozilla.org
Date: Fri, 07 Feb 2014
On 8 February 2014 12:26, Benjamin (Inglor) Gruenbaum ing...@gmail.comwrote:
On Sat, Feb 8, 2014 at 2:57 PM, Quildreen Motta quildr...@gmail.comwrote:
One of the problems with just following existing solutions is that you'd
also be copying the evolution mistakes and technical debts in those
74 matches
Mail list logo
