/methods and returns that. Internally, the methods can still access
the private (unexposed) members, but from the outside, with access only to
the proxy, they would be hidden. I think this would avoid the need for the
private key feature that has also been proposed.
Thanks,
Russell Leggett
I'm probably not the first to have thought of this, but it seemed like
the most minimal class support I could think of, and it sounds like
that's where things are headed from the lack of agreement. Through the
additions made by the Set Literal Prototype operator proposal, I think
you nailed 90% of
On Sat, Oct 1, 2011 at 3:42 PM, Axel Rauschmayer a...@rauschma.de wrote:
Note that in JavaScript terminology, a class is a function (which in turn is
an object). So there really are no classes. Just functions that produce
instances when used with the new operator (if a function is used this
I'm not opposed to the class literal as much as I was trying to think of the
most minimal classes that could find some consensus. It seems from the
discussion that if no syntax can be agreed on, then perhaps it would have to
wait for ES.next.next.
The problem with the class literal syntax that
On Sun, Oct 2, 2011 at 3:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It's only a one character change but it eliminates the hazard that some
people are concerned about of leaving off the .constructor or
.constructor.{...} at the end of the pattern. Also, I can imagine that
On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 2, 2011, at 1:32 PM, Russell Leggett wrote:
...
I can see the recursive stache useful in some situations (although
it is another syntax addition to object literals). It would allow for
the ability to apply
On Oct 2, 2011, at 8:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Oct 2, 2011, at 5:02 PM, Russell Leggett wrote:
On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Is that the
SuperClass | {
...
}
part evaluates
On Mon, Oct 3, 2011 at 4:49 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Dear All,
while I had the opportunity to ask directly to Brendan Eich this
question, I would like to ask you 5 minutes of your precious time to
understand common concerns from the JS community, summarized
On Mon, Oct 3, 2011 at 9:37 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
On Mon, Oct 3, 2011 at 17:25, Brendan Eich bren...@mozilla.com wrote:
If so we are at an impasse. To get past it, we would need to agree on
declarative syntax and semantics preventing use before initialization. We
On Tue, Oct 4, 2011 at 3:44 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 4, 2011, at 5:43 AM, Russell Leggett wrote:
I don't want to be pushy, so this is the last time that I'll mention
it, but if we can create something using the | operator that can
basically do what has been discussed
On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel mikesam...@gmail.com wrote:
No it doesn't.
Just walk the object graph starting from the root object and let the
set of all reachable symbols be A.
Load jQuery
Walk the object graph again letting the set of all reachable symbols be B.
The public
On Wed, Oct 5, 2011 at 10:32 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel mikesam...@gmail.com wrote:
2011/10/4 Russell Leggett russell.legg...@gmail.com:
On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel mikesam...@gmail.com
wrote
On Wed, Oct 5, 2011 at 10:52 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett russell.legg...@gmail.com
wrote:
On Wed, Oct 5, 2011 at 10:32 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Tue, Oct 4, 2011 at 10:26 AM, Mike
On Wed, Oct 5, 2011 at 11:48 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Here again I am not sure how we ended up with this conversation but you can
find a function able to extract properties and methods out of a generic
object:
https://gist.github.com/1264775
It works with
On Wed, Oct 5, 2011 at 11:49 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett russell.legg...@gmail.com
wrote:
On Wed, Oct 5, 2011 at 10:52 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Wed, Oct 5, 2011 at 7:49 AM, Russell
On Wed, Oct 5, 2011 at 12:04 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
with such dynamic language I would never trust much AST
This is for realtime, inline, methods and properties suggestion and it's
kinda fast as macro/inspector
I don't know where the thread is going either :-)
On Wed, Oct 5, 2011 at 10:03 AM, Claus Reinke claus.rei...@talk21.com wrote:
Just walk the object graph starting from the root object and let the
set of all reachable symbols be A.
Load jQuery
Walk the object graph again letting the set of all reachable symbols be
B.
The public API of jQuery
On Wed, Oct 5, 2011 at 1:18 PM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett russell.legg...@gmail.com
wrote:
On Wed, Oct 5, 2011 at 11:49 AM, John J Barton
johnjbar...@johnjbarton.com wrote:
On Wed, Oct 5, 2011 at 8:05 AM, Russell
On Oct 7, 2011, at 6:51 AM, Mikeal Rogers mikeal.rog...@gmail.com wrote:
On Thu, Oct 6, 2011 at 5:08 AM, Brendan Eich bren...@mozilla.com wrote:
On Oct 4, 2011, at 10:52 AM, Mikeal Rogers wrote:
But, some of them simply double the semantics and syntax in the language
without a path
On Thu, Oct 13, 2011 at 12:46 PM, Douglas Crockford
doug...@crockford.comwrote:
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, and productivity should be higher with
CoffeeScript
[snip]
I want to compose objects:
var result = cookUpTheBehavior(goodies, stuff) |
initializeTheState(args);
You want something else, then. Just because you want B does not mean A
is useless or less useful or not JavaScripty.
With a decent Object.extend() we'd have a clean way to
I have been thinking that proxies could be a nice way of having private data
members instead of the private name proposal. The target would be the full
implementation, including all private members done as normal properties.
Then the implementation object would get wrapped with a proxy, exposing
On Tue, Oct 18, 2011 at 4:28 PM, Brendan Eich bren...@mozilla.com wrote:
On Oct 18, 2011, at 1:25 PM, Russell Leggett wrote:
I have been thinking that proxies could be a nice way of having private
data members instead of the private name proposal. The target would be the
full implementation
On Mon, Oct 31, 2011 at 9:57 PM, Jeremy Ashkenas jashke...@gmail.comwrote:
'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 proposal for minimalist
There are many more, I'm sure, but the point is this: a syntax that makes
use of the elements already in the language (instead of providing
alternates) is going to be more familiar and therefore objectively more
intuitive. Yes, the class keyword brings some new wrinkles, but that will
be
I know this will be controversial, but I would prefer only having the
expression form. The reason is that
let Monster = Being | mylib.mixin(Evil, Scary) | class {...}
is an important usecase and it is harder to make the syntax work with a
pure class declaration.
I'm not sure if you
On Nov 11, 2011, at 6:55 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Nov 11, 2011, at 3:39 PM, Oliver Hunt wrote:
A weak map can only remove an entry if both the key and value have died, in
many ES implementations a number of the primitives are not gc allocated and
so can
Sorry I'm late to the party, I'm just catching up now. I'm glad that what I
proposed got mentioned (thanks Brendan), but I wanted to be clear that its
not actually what Allen is proposing here. Where Allen is proposing a
simple sugar operator to retrieve the constructor, I was proposing an
On Tue, Nov 15, 2011 at 1:01 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 15, 2011, at 9:56 AM, Brendan Eich wrote:
On Nov 15, 2011, at 8:16 AM, Russell Leggett wrote:
I think this example is contrived, but illustrates the point that
JavaScript is very dynamic, and sometimes
On Nov 15, 2011, at 5:45 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 15, 2011, at 10:34 AM, Russell Leggett wrote:
Yes, of course you're right about that. There was something in the back of
my brain saying there might be a problem with that optimization, but I had
hoped it could
Given the recent conversation about class as operator and its likely
composition with |, I propose turning the syntax:
*MemberExpression* | *ProtoLiteral*
into
extends *MemberExpression ProtoLiteral*
In the common case of using the class operator, it would read much more
naturally:
since in this example I only used the object literal variant. (The function,
array, etc variants do things that Object.create can't do.)
I think this is ultimately the downfall of 'with' as a complete replacement for
| or extends. It works pretty well on objects but no others.
SomeFunc
On Thu, Nov 17, 2011 at 8:08 AM, David Herman dher...@mozilla.com wrote:
On Nov 17, 2011, at 3:53 AM, Dmitry Soshnikov wrote:
Once again, it's absolutely the same approach which I showed yesterday
with using `extends' (
On Thu, Nov 17, 2011 at 12:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
OK, I have a fix for the missing constructor problem. See:
http://wiki.ecmascript.org/doku.php?id=strawman:class_operator#missing_constructors
The biggest thing I see missing is a declarative form that includes
On Thu, Nov 17, 2011 at 3:06 PM, David Flanagan dflana...@mozilla.comwrote:
On 11/16/11 11:45 AM, Erik Arvidsson wrote:
Sorry for being too brief. Today the following works.
f();
...
function f() { ... }
but the following does not:
f();
...
let f = function f() {};
I think it is
It is also something that my proposed version of the class operator could
do, because it always creates a function, and could desugar to the same
semantics as the current function style.
This may seem like a nit-pick, but I think it's not: any variant that sits
at statement context in the
On Fri, Dec 30, 2011 at 6:53 AM, David Bruant bruan...@gmail.com wrote:
Le 30/12/2011 02:28, John J Barton a écrit :
On Thu, Dec 29, 2011 at 5:11 PM, David Bruant bruan...@gmail.com wrote:
Le 30/12/2011 01:00, Lasse Reichstein a écrit :
On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller
If you desperately need it, you should be able to make a library for it,
and then if you need the extra syntax, add an extra compile step - like
what coffeescript does. After all, e4x is just an extension to JS, it
should be possible to add the data types natively and then make any e4x
code work
On Tue, Jan 17, 2012 at 1:30 PM, Grant Husbands esdisc...@grant.x43.netwrote:
Russell Leggett wrote:
If you desperately need it, you should be able to make a library for it,
and
then if you need the extra syntax, add an extra compile step
I was simply making sure everyone was on the same
On Mon, Jan 23, 2012 at 5:37 AM, Herby Vojčík he...@mailbox.sk wrote:
Allen Wirfs-Brock wrote:
The following is just speculation...One possible such bottleneck
might be whole object allocation. A JS clone function probably would
have to allocate an empty object and then dynamically populate
As part of the HTML5 specification, there is the structured clone
algorithmhttp://www.w3.org/TR/html5/common-dom-interfaces.html#safe-passing-of-structured-data
Which is also incapable of copying a function.
True, but the original suggestion was limited only to the json subset.
On Wed, Feb 29, 2012 at 9:52 AM, Rick Waldron waldron.r...@gmail.comwrote:
Despite my comments about not letting archaic browsers dictate our future,
which still stands...
On Wed, Feb 29, 2012 at 3:40 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I agree add/remove is more
I believe is has effectively been added under the more constrained object
literal extensions
http://wiki.ecmascript.org/doku.php?id=harmony:object_literals
On Tue, Mar 6, 2012 at 12:50 PM, Isaac Schlueter i...@izs.me wrote:
A great many letters have been typed regarding the number of letters
2012/3/6 Brendan Eich bren...@mozilla.org
程劭非 wrote:
I am just thinking we need a way to serialize/unserialize a js object
with circular reference to itself.
Not just circular references, join points as well (anything making the
object graph not a tree).
As Allen suggested, with ES6
On Wed, Mar 7, 2012 at 4:41 AM, Andreas Rossberg rossb...@google.comwrote:
I'm a little bit confused here. Wasn't arrow syntax (args) - expr
shot down earlier because it is too difficult to parse for both human
and machine? I don't understand how (args) expr can possibly be any
better in this
On Wed, Mar 7, 2012 at 2:58 AM, David Bruant bruan...@gmail.com wrote:
Le 07/03/2012 02:10, Brandon Benvie a écrit :
I start this coming from the standpoint of an honest question that I
don't know the answer to: is there a specific reason that objects
can't be callable in js? Aside from
On Wed, Mar 7, 2012 at 4:56 PM, Isaac Schlueter i...@izs.me wrote:
This might be a dumb question: TCP = this-context preservation?
(Sorry, my brain has that acronym hard-linked to Transport Control
Protocol and I keep getting confused.)
TCP = Tennent's Correspondence Principle
Yehuda Katz
Its mostly about being able to make control abstractions - being able to
make your own loops, conditionals, DSLs - and while you can get close with
anonymous functions, you'll never get there, because someone will want to
use 'return' or 'break' or 'throw' and the behavior is all screwed up (as
we
On Thu, Mar 8, 2012 at 8:43 AM, Herby Vojčík he...@mailbox.sk wrote:
Russell Leggett wrote:
Its mostly about being able to make control abstractions - being able to
make your own loops, conditionals, DSLs - and while you can get close
with anonymous functions, you'll never get
On Thu, Mar 8, 2012 at 9:35 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
I was thinking and playing with something similar ... here an example:
http://www.3site.eu/functionize/
Looks like the function keyword could actually be dropped easily without
compromising the syntax too
Bound this would be nice, since it is a new form that can't break existing
code.
Yes - I think this could be pretty excellent - no pun intended. I think
think it would be a great compromise between current functions and full TCP.
- Russ
--
John A. Tamplin
Software Engineer (GWT),
Thanks for throwing out alternative syntaxes. We should keep beating on
this anvil, shorter function syntax is well worth it. But we need a non-GLR
parsing procedure that rejects ambiguous grammars.
So here's my pitch - I've been thinking over a lot of the different
syntaxes that have been
I know it's just bikeshedding, but do you need the - arrow (it is better
visually)? You can as well take arrowless approach but putting : before
every parameter (as I suggested):
// ':' is the clue that this is the start of a short function
coll.map(:x - x*x) //function(x){ return
On Sat, Mar 10, 2012 at 3:10 PM, Herby Vojčík he...@mailbox.sk wrote:
Hello,
to see the problem various syntaxes can bring, various crazy code samples
should be written in each of them to see if and how hard can they be used,
and how it is readable.
I created a little gallery of a few code
Add such examples. I made it editable for anyone exactly for that reason - to
add code samples they see as relevant.
Will do
- Russ
Herby
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Can you answer the 'cost' side of the BTF issue? That is if BTF was
really easy, how many times would we have to opt-out so we can use the
default value of this? My guess: you will need a lot zeros in place
of X in 0.0X% ;-)
Sometimes the 'this' is not needed at all; does it ever matter
On Mar 13, 2012, at 8:49 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Tue, Mar 13, 2012 at 1:00 PM, Russell Leggett russell.legg...@gmail.com
wrote:
Can you answer the 'cost' side of the BTF issue? That is if BTF was
really easy, how many times would we have to opt-out so we can use
On Fri, Mar 16, 2012 at 4:26 PM, Kevin Smith khs4...@gmail.com wrote:
Thanks, David.
First, I'd like to point out that in the blog post I'm putting on the hat
of a library author (I happen to be one, but that's beside the point).
One of the first conclusions that I come to (as a library
Given the recent go at finding alternative syntax for the | operator, I
thought about it and decided to split the functionality between creating
instances using alternative prototypes, and the other side of the fence
making reusable extended objects easier to make.
Its a little long so I threw it
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using : instead of |, shorten Email.prototype to just Email
let email = Email:russell.legg...@gmail.com;
Basically you are saying
On Mar 17, 2012, at 12:18 PM, Kevin Smith khs4...@gmail.com wrote:
Currently, | sets the [[prototype]] field of the RHS object,
and -if the RHS is a function literal- also specifies the [[prototype]]
field of objects generated from it. I suggest to remove that special
case for function RHS.
On Mar 17, 2012, at 12:31 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Mar 17, 2012, at 9:14 AM, Russell Leggett wrote:
On Mar 17, 2012, at 11:39 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
...
//using
On Sat, Mar 17, 2012 at 1:09 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 17, 2012, at 2:03 AM, Russell Leggett wrote:
Given the recent go at finding alternative syntax for the | operator, I
thought about it and decided to split the functionality between creating
instances using
The recent discussion “Using Object Literals as Classes” brought up some
key points, but the general feeling I got and agree with is this: we need
to get classes into ES6. As Kevin points out, even if it didn’t have all of
the features (like mixins) that most class libs have, he would use an
I would propose that the absolute minimal requirements would be:
- has a declaration form that uses the class keyword and an
identifier to create the class
- has a body that can include both the constructor function, as well
as any instance (prototype) methods – including getter
On Tue, Mar 20, 2012 at 2:09 PM, Rick Waldron waldron.r...@gmail.comwrote:
[ ... snip ]
class Animal {
constructor(name){
this.name = name;
}
move(meters){
alert(this.name + moved + meters + m.);
}
}
Russ,
I'm trying to write up some
* has a declaration form that uses the class keyword and an
identifier to create the class
Why to rule out other possibilities (though I understand this one is the
least surprise one)?
I'm not sure I understand what you are asking, but I think you answered
your own question.
, at 1:03 PM, Russell Leggett wrote:
The recent discussion “Using Object Literals as Classes” brought up some
key points, but the general feeling I got and agree with is this: we need
to get classes into ES6. As Kevin points out, even if it didn’t have all of
the features (like mixins) that most
On Tue, Mar 20, 2012 at 3:30 PM, Kevin Smith khs4...@gmail.com wrote:
class Snake extends Animal {
constructor(name){
super(name);
}
Another option here would be:
class Snake extends Animal {
// Using new ; )
new(name) : super(name) {}
};
Note the call to
On Tue, Mar 20, 2012 at 3:34 PM, Rick Waldron waldron.r...@gmail.comwrote:
Another option here would be:
class Snake extends Animal {
// Using new ; )
new(name) : super(name) {}
};
This could be visually mistaken for an object literal.
Did I mention controversy? :) Also - it
On Tue, Mar 20, 2012 at 3:55 PM, Herby Vojčík he...@mailbox.sk wrote:
Russell Leggett wrote:
On Tue, Mar 20, 2012 at 2:55 PM, David Herman dher...@mozilla.com
mailto:dher...@mozilla.com wrote:
Yes, I debated about this. In fact, I almost did go with new.
Personally, I'm fine with either. I
On Tue, Mar 20, 2012 at 3:58 PM, Kevin Smith khs4...@gmail.com wrote:
Yeah - Java enforces this by making it an error if a call to super happens
after any other statement.
Yes - and magically interleaving instance field initializers in between
the super call and the rest of the constructor
I don't know if I would write:
class Foo extends Bar {
constructor (x) { ... }
method1 () {}
method2 () {}
}.prototype.{
commonNum: 0,
commonColl: []
}
or
function Foo (x) extends Bar {
...
}.prototype.{
method1 () {}
method2 () {}
commonNum: 0,
On Wed, Mar 21, 2012 at 7:03 AM, Herby Vojčík he...@mailbox.sk wrote:
Allen Wirfs-Brock wrote:
We can live quite nicely with treating class declaration like const
declarations. The name is logically hoisted so it is visible over the
lexical scope, but the name is temporally dead until the
On Wed, Mar 21, 2012 at 9:35 AM, Kevin Smith khs4...@gmail.com wrote:
Hi Axel,
We should probably hold off on private and static member syntax until
there's consensus on the other open issues:
Yeah, we can't add any features on the safety syntax, we'll get back to
where we started. Kevin
On Wed, Mar 21, 2012 at 11:12 AM, Kevin Smith khs4...@gmail.com wrote:
1. I think its easier to explain - it will actually result in a
constructor on the prototype.
2. The actual constructor function and the .constructor property
really should always be in sync - this helps with
Anyway, unless we are going to really make classes distinct from
functions, I'm not sure how we could enforce super in the way you describe
without affecting it in other forms. Can you only extend classes created
using class syntax?
No - any function (constructor) can be to the right of
On Wed, Mar 21, 2012 at 1:49 PM, Brendan Eich bren...@mozilla.org wrote:
Herby Vojčík wrote:
That brings the question: what about static block? I think it should have
exactly same rules as the basic class block (sans possibility having its
own nested static block). That is, what about that
On Wed, Mar 21, 2012 at 2:25 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 21, 2012, at 6:25 AM, Russell Leggett wrote:
...
Yeah - that is the way I was leaning, partly because I like it, and partly
because that was the behavior in | for functions in the class pattern. I
think
On Wed, Mar 21, 2012 at 2:47 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 21, 2012, at 8:41 AM, Russell Leggett wrote:
On Wed, Mar 21, 2012 at 11:12 AM, Kevin Smith khs4...@gmail.com wrote:
1. I think its easier to explain - it will actually result in a
constructor
That said, it requires no more code to say:
// jquery.js
export function $(selector) { ... }
...
// client
import $ from jquery.js;
let elements = [foo, bar, baz].map($);
$(quux).style(...);
So maybe people have over-sold the importance of callable modules. In
On Fri, Mar 23, 2012 at 12:30 AM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Allen has argued against hoisting, based on the extends clause being an
evaluated expression.
Also (if included) based on static property initializers being evaluated,
intuitively in
On Fri, Mar 23, 2012 at 1:38 AM, Brendan Eich bren...@mozilla.org wrote:
Russell Leggett wrote:
This is what Allen said about hoisting for this spec (Its been a long
thread, not sure if you missed this.):
Thanks, I did catch up that far on the thread, but Allen reiterated the
point he'd
On Fri, Mar 23, 2012 at 7:00 AM, Herby Vojčík he...@mailbox.sk wrote:
Andreas Rossberg wrote:
On 23 March 2012 08:42, Claus Reinke claus.rei...@talk21.com
mailto:claus.reinke@talk21.**com claus.rei...@talk21.com wrote:
- would it make sense to name the constructor after the class
On Fri, Mar 23, 2012 at 12:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Mar 23, 2012, at 12:42 AM, Claus Reinke wrote:
- could we think of hoisting a class as hoisting its constructor
(the hoisted binding wouldn't be undefined, but shouldn't be
called before
On Fri, Mar 23, 2012 at 2:06 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
We need to overcome at least one TC39er who values
requiring an error for
use-before-init for instance properties, perhaps only if const or
guarded, so (I hope) we can defer those without being
On Fri, Mar 23, 2012 at 3:40 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Mar 23, 2012, at 11:33 AM, Russell Leggett wrote:
On Fri, Mar 23, 2012 at 2:06 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
We need to overcome at least one TC39er who values
requiring
On Fri, Mar 23, 2012 at 4:17 PM, Brendan Eich bren...@mozilla.org wrote:
Russell Leggett wrote:
Yeah, that's one of the things that confused me. Brendan specified
instance properties, which made me think he was referring to an error that
might occur prior to actually evaluating the code
On Mar 23, 2012, at 9:05 PM, John Tamplin j...@google.com wrote:
On Fri, Mar 23, 2012 at 8:21 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
Does passing /foo/i.test not work? (Away from computer.) Perhaps it should,
if it doesn't?
It does, if you bind it to the regex first.
This seems special purpose enough (as you say, for legacy formats) and easy
enough to implement, that it probably doesn't warrant being included in the
language.
- Russ
On Mar 23, 2012, at 5:36 PM, Roger Andrews roger.andr...@mail104.co.uk
wrote:
String.prototype.split is good for cutting
Finally, regarding:
d) an explicit 'constructor' method overrides the implicit creation
of the 'constructor' method but does not define the constructor function
Why d)? Remember, the .constructor idiom is a *very weak* idiom that
many JS programs don't follow. If a JS program has
On Tue, Mar 27, 2012 at 1:09 PM, David Herman dher...@mozilla.com wrote:
On Mar 26, 2012, at 10:32 PM, Brendan Eich wrote:
This is actually one of the reasons I still come down on constructor
over new - I'd really like to discourage screwing around with
ctor.prototype.constructor. That
On Tue, Mar 27, 2012 at 2:59 PM, Brendan Eich bren...@mozilla.com wrote:
Russell Leggett wrote:
Can we make it writable:false, configurable:true? Of course, that would
only be a minor deterrent from changing it around, but maybe just enough?
This has zero integrity, so is IMHO worse than
On Tue, Mar 27, 2012 at 3:43 PM, Brendan Eich bren...@mozilla.com wrote:
http://wiki.ecmascript.org/**doku.php?id=strawman:arrow_**function_syntaxhttp://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax
Use = only with an expression body (do-expressions if accepted allow
On Mar 27, 2012, at 10:36 PM, Kevin Smith khs4...@gmail.com wrote:
But aren't non-BTFs rare based on your (revised and original) measurements?
When you take out the object literal methods, that's right.
The precise way to say it would be that ~90% of function expressions in the
code I
On Wed, Mar 28, 2012 at 1:37 PM, David Herman dher...@mozilla.com wrote:
On Mar 27, 2012, at 9:14 PM, Russell Leggett wrote:
I'm sure this is a bit of a tangent, but the other major related case is
passing a method as an argument but needing to retain the correct this.
Obviously
On Wed, Mar 28, 2012 at 2:38 PM, John Tamplin j...@google.com wrote:
On Wed, Mar 28, 2012 at 2:02 PM, Russell Leggett
russell.legg...@gmail.com wrote:
Ah, there you go. I figured I wasn't the first to think of it. I think it
might be worth talking about this in relation to the shorthand
On Wed, Mar 28, 2012 at 3:17 PM, Kevin Smith khs4...@gmail.com wrote:
I'm not sure how to quantify this, but I believe that if such a bind
operator were available, it would be overwhelmingly be used to simulate
lexical |this|.
If syntax is about optimizing the common case, then shouldn't we
On Wed, Mar 28, 2012 at 3:57 PM, Kevin Smith khs4...@gmail.com wrote:
Russell, I looked at the other thread more carefully and now understand
what you're saying. Can't we use a bound |this| function for all these
cases?
needsCallback(x = foo.bar(x));
needsCallback(x = this.bar(x));
will post soon.
- Russ
On Wed, Mar 28, 2012 at 10:37, David Herman dher...@mozilla.com wrote:
On Mar 27, 2012, at 9:14 PM, Russell Leggett wrote:
I'm sure this is a bit of a tangent, but the other major related case
is passing a method as an argument but needing to retain the correct
1 - 100 of 221 matches
Mail list logo
