Re: Proxy-induced impurity of internal methods

On 6 October 2011 06:34, Allen Wirfs-Brock wrote: > On Oct 5, 2011, at 9:57 AM, Andreas Rossberg wrote: >> In summary, I'm slightly worried. The above all seems fixable, but is >> that all? Ideally, I'd like to see a more thorough analysis of how the >> addition of proxies affects properties of th

Re: traits feedback

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. PrototypeJS is IIRC 2005-era. Firebug is post-y2k. > so their implementation was just what could be done, not what was desired. Seems u

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Oct 4, 2011, at 7:36 PM, Dean Landolt wrote: > I think generators are an excellent example of a feature that is well > prototyped (in FF JS 1.7+). I think the developer uptake is minimal, outside > of the original advocates. > > Of course uptake is minimal -- it's only in one engine, and eve

Re: On "I got 99 problems and JavaScript syntax ain't one"

A huge +1 and hugs and kisses for your entire post. And I didn't say anything like Mikeal's paraphrase, and the ES6 harmony:proposals bear this out (<| is unsexy in my current font!). It's especially important not to discount shorthands and sugar for cliché, even though they could be replaced b

Re: Proxy-induced impurity of internal methods

Good points that we will have to specify careful. Also one the reasons we do prototype implementations. Such issues seems inherent in the adoption of an intercession API and semantics. Having to deal with such issues isn't really new. In ES5 we had to deal with this possibility WRT [[Get]] a

Re: On "I got 99 problems and JavaScript syntax ain't one"

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 to deprecate previous syntax. I'm a big fan of let, but if you > don't deprecate var we're going to have to contend with new programmers > keeping two se

Re: traits feedback

On Wed, Oct 5, 2011 at 8:44 PM, Brendan Eich wrote: > On Oct 5, 2011, at 8:21 PM, John J Barton wrote: > > I think what's missing is Object.extend: > > http://www.prototypejs.org/api/object/extend > http://api.jquery.com/jQuery.extend/ > http://dojotoolkit.org/reference-guide/dojo/extend.html > >

Re: traits feedback

On Oct 5, 2011, at 8:21 PM, John J Barton wrote: > I think what's missing is Object.extend: > > http://www.prototypejs.org/api/object/extend > http://api.jquery.com/jQuery.extend/ > http://dojotoolkit.org/reference-guide/dojo/extend.html > http://docs.sencha.com/ext-js/4-0/source/Object2.html#Ext

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Oct 5, 2011, at 8:01 PM, Quildreen Motta wrote: > On 05/10/11 23:06, Brendan Eich wrote: >>> `==' (Abstract equality) is used for comparing the value of two objects, >>> without taking data-structure into account. >> This operator is insane due to implicit conversions it does when operand >>

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Thu, Oct 6, 2011 at 12:01 AM, Quildreen Motta wrote: > 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: - A sane way of dealing w

Re: traits feedback

On Wed, Oct 5, 2011 at 8:02 PM, Juan Ignacio Dopazo wrote: > On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten wrote: > >> Object.create does indeed require propertydescriptors as the second >> argument. This is the easiest way to send meta-data like read-only. >> >> However it's verbose and the de

Re: traits feedback

On 06/10/11 00:02, Juan Ignacio Dopazo wrote: On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten > wrote: Object.create does indeed require propertydescriptors as the second argument. This is the easiest way to send meta-data like read-only. However it's v

Re: traits feedback

On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten wrote: > Object.create does indeed require propertydescriptors as the second > argument. This is the easiest way to send meta-data like read-only. > > However it's verbose and the defaults are restrictive. I've written a small > library (github.com/

Re: On "I got 99 problems and JavaScript syntax ain't one"

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 h

Re: On "I got 99 problems and JavaScript syntax ain't one"

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 here have noted. >>> >>> How

Re: On "I got 99 problems and JavaScript syntax ain't one"

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 bo

Re: traits feedback

Object.create does indeed require propertydescriptors as the second argument. This is the easiest way to send meta-data like read-only. However it's verbose and the defaults are restrictive. I've written a small library (github.com/Raynos/pd) to make it less verbose, you might find it useful. On

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: OnIncremental Updates)

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 both > syntax and APIs. We need: >

Re: traits feedback

On Tue, Oct 4, 2011 at 8:56 PM, John J Barton wrote: > In trying to update my JS approach I looked into 'traits'. I'm still on the > fence about using them at this stage, but MarkM was asking for feedback of > pretty much any kind so here is a little. > > I believe I understand traits for the most

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 2:25 PM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 1:18 PM, John J Barton > 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 > >> wrote: > >> > > >> >

Re: holes in spread elements/arguments

Removing these inconsistencies would also allow argument and parameter lists to be explained in terms of desugaring into array structuring and destructuring patterns respectively: function(a, , c = 0, ...d){  //...} would desugar to: function(){  var [a, , c = 0, ...d] = _arguments_; // even better

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 1:18 PM, John J Barton wrote: > > > On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett > wrote: >> >> On Wed, Oct 5, 2011 at 11:49 AM, John J Barton >> wrote: >> > >> > >> > On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett >> > >> > wrote: >> >> >> >> On Wed, Oct 5, 2011 at 1

Re: holes in spread elements/arguments

On Mon, Oct 3, 2011 at 4:37 PM, Allen Wirfs-Brock wrote: > apply supports holes... > > f.apply(Array(5)); > > Look at the specification of apply in section 15.3.4.3 of the ES5/5.1 spec. >  It does a [[Get]] on each element of the argArray to get the value that > passed in the argument list.  [[Get

Re: Proxy-induced impurity of internal methods

On 5 October 2011 18:57, Andreas Rossberg wrote: > FIXING PROXIES > > A particularly worrisome side effect is fixing a proxy. The proxy > semantics contains a lot of places saying "If O is a trapping proxy, > do steps I-J." However, there generally is no guarantee that O remains > a trapping proxy

Re: Sep 27 meeting notes

On Oct 4, 2011, at 8:35 AM, Allen Wirfs-Brock wrote: > On Oct 4, 2011, at 12:44 AM, Brendan Eich 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

Re: Sep 27 meeting notes

On Oct 4, 2011, at 6:17 AM, Russell Leggett wrote: > That's why I was trying to make it less error prone and verbose. Understood, but we should not "scenario solve" with ad-hoc, compound additions. We seek orthogonal primitives that compose well, and the harder scenarios ideally desugar. >> I

Re: Proxy-induced impurity of internal methods

Please keep bringing these up; they're important. This is something that we'll need to get nailed down for the spec. Yes, I'm worried too, as this problem is not well-understood. It has the feel of a research problem. Waldemar ___ es-discuss ma

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Wed, Oct 5, 2011 at 7:18 AM, John J Barton wrote: > > > On Tue, Oct 4, 2011 at 2:33 PM, Bob Nystrom wrote: > >> That's correct. That's often the cost of concision. By analogy: you can do >> a lot of stuff using either an explicit stack data structure or recursion. >> Using recursion is often m

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 9:11 AM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 11:49 AM, John J Barton > 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 > >> wrote: > >> > > >>

Proxy-induced impurity of internal methods

Proxies invalidate one fundamental assumption of the current ES spec, namely that (most) internal methods are effectively pure. That has a couple of consequences which the current proxy proposal and semantics seem to ignore, but which we need to address. OBSERVABILITY & EFFICIENCY In ES5, intern

Minor issues with proxies

Hi Mark, Tom! I understand that you are currently working on finalizing a number of aspects of the proxies proposal, so I thought I'd send my current notes on issues I discovered. (Sorry if I'm a bit late with that, but I just returned from travelling.) Here is a list of minor issues. I'll send a

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

Sorry Russ, I am not sure I got it On Wed, Oct 5, 2011 at 6:14 PM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 12:04 PM, Andrea Giammarchi > wrote: > > with such dynamic language I would never trust much AST > > This is for realtime, inline, methods and properties suggestion and it's > > kin

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: OnIncremental Updates)

On Wed, Oct 5, 2011 at 10:03 AM, Claus Reinke 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

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Wed, Oct 5, 2011 at 10:18 AM, John J Barton wrote: > > > On Tue, Oct 4, 2011 at 2:33 PM, Bob Nystrom wrote: > >> >> >> On Tue, Oct 4, 2011 at 2:12 PM, John J Barton < >> johnjbar...@johnjbarton.com> wrote: >> >>> >>> >>> On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom wrote: >>> A const

Re: String concatenation

On Wed, Oct 5, 2011 at 12:10 PM, Axel Rauschmayer wrote: > The two concatenation approaches I know of are: >> 1. via += >> 2. push() into an array, join() it after the last push() >> >> (1) can’t possibly be efficient, > > > Huh? Engines have optimized the hell out of 1 by essentially doing 2 un

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 12:04 PM, Andrea Giammarchi 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 :-) It would also break as

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 11:49 AM, John J Barton wrote: > > > On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett > wrote: >> >> On Wed, Oct 5, 2011 at 10:52 AM, John J Barton >> wrote: >> > >> > >> > On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett >> > >> > wrote: >> >> >> >> On Wed, Oct 5, 2011 at

Re: String concatenation

> The two concatenation approaches I know of are: > 1. via += > 2. push() into an array, join() it after the last push() > > (1) can’t possibly be efficient, > > Huh? Engines have optimized the hell out of 1 by essentially doing 2 under > the hood. Even rhino's about a land a patch to do just th

Re: String concatenation

On 05.10.2011 19:45, Axel Rauschmayer wrote: Is this worthy of ES.next support? Or does it belong into a library? The two concatenation approaches I know of are: 1. via += 2. push() into an array, join() it after the last push() (1) can’t possibly be efficient, but if (2) is OK on all(!) platfo

Re: String concatenation

On Wed, Oct 5, 2011 at 11:45 AM, Axel Rauschmayer wrote: > Is this worthy of ES.next support? Or does it belong into a library? > > The two concatenation approaches I know of are: > 1. via += > 2. push() into an array, join() it after the last push() > > (1) can’t possibly be efficient, Huh? En

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

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 5:57 PM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 11:48

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 8:57 AM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 11:48 AM, Andrea Giammarchi > 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:

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 11:48 AM, Andrea Giammarchi 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 jQuery too, as well as array

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 8:05 AM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 10:52 AM, John J Barton > 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 > >> wrote: > >> > > >>

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

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 jQuery too, as well as arrays, etc etc Regards, Andrea Giammarchi __

String concatenation

Is this worthy of ES.next support? Or does it belong into a library? The two concatenation approaches I know of are: 1. via += 2. push() into an array, join() it after the last push() (1) can’t possibly be efficient, but if (2) is OK on all(!) platforms, then a library would be OK. However, give

Re: traits feedback

On Wed, Oct 5, 2011 at 8:21 AM, Dean Landolt wrote: > > > On Wed, Oct 5, 2011 at 10:48 AM, John J Barton < > johnjbar...@johnjbarton.com> wrote: > >> >> >> On Wed, Oct 5, 2011 at 12:52 AM, Tom Van Cutsem wrote: >> >>> Thanks for the feedback, John. >>> >>> I have to admit that at first I was also

Re: traits feedback

On Wed, Oct 5, 2011 at 10:48 AM, John J Barton wrote: > > > On Wed, Oct 5, 2011 at 12:52 AM, Tom Van Cutsem wrote: > >> Thanks for the feedback, John. >> >> I have to admit that at first I was also taken aback by the apparent >> complexity of the "syntax for efficient traits" strawman. Traits have

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 10:52 AM, John J Barton wrote: > > > On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett > wrote: >> >> On Wed, Oct 5, 2011 at 10:32 AM, John J Barton >> wrote: >> > >> > >> > On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel >> > wrote: >> >> >> >> 2011/10/4 Russell Leggett : >>

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 7:49 AM, Russell Leggett wrote: > On Wed, Oct 5, 2011 at 10:32 AM, John J Barton > wrote: > > > > > > On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel > wrote: > >> > >> 2011/10/4 Russell Leggett : > >> > On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel > >> > wrote: > >> > > >>

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Wed, Oct 5, 2011 at 10:32 AM, John J Barton wrote: > > > On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel wrote: >> >> 2011/10/4 Russell Leggett : >> > On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel >> > wrote: >> > >> >> No it doesn't. >> >> >> >> Just walk the object graph starting from the root

Re: traits feedback

On Wed, Oct 5, 2011 at 12:52 AM, Tom Van Cutsem wrote: > Thanks for the feedback, John. > > I have to admit that at first I was also taken aback by the apparent > complexity of the "syntax for efficient traits" strawman. Traits have many > knobs, and require a lot of syntax to turn these knobs. >

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: On Incremental Updates)

On Tue, Oct 4, 2011 at 10:26 AM, Mike Samuel wrote: > 2011/10/4 Russell Leggett : > > On Tue, Oct 4, 2011 at 12:51 PM, Mike Samuel > 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 jQu

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Tue, Oct 4, 2011 at 2:33 PM, Bob Nystrom wrote: > > > On Tue, Oct 4, 2011 at 2:12 PM, John J Barton > wrote: > >> >> >> On Tue, Oct 4, 2011 at 12:59 PM, Bob Nystrom wrote: >> >>> >>> A constructor is different from a regular function. Instead of returning >>> the value that the body of the f

Re: On "I got 99 problems and JavaScript syntax ain't one" (was: OnIncremental Updates)

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 is then (B - A). That's works fine under 2 conditions: 1. You're willing to exec

Re: On "I got 99 problems and JavaScript syntax ain't one"

That's very nice, thanks. On Wed, Oct 5, 2011 at 12:23 PM, Andrea Giammarchi < andrea.giammar...@gmail.com> wrote: > dunno how we ended up here but I would rather use this approach in a > private scope: > > var > // used to trap function calls via bind > invoke = Function.call, > // n

Re: On "I got 99 problems and JavaScript syntax ain't one"

dunno how we ended up here but I would rather use this approach in a private scope: var // used to trap function calls via bind invoke = Function.call, // normal use cases bind = invoke.bind(invoke.bind), apply = bind(invoke, invoke.apply), call = bind(invoke, invoke) ; va

Re: On "I got 99 problems and JavaScript syntax ain't one"

Le 05/10/2011 10:33, Mark S. Miller a écrit : Since you're assuming you can initialize and grab stuff before your context is corrupted, what's wrong with Lasse's earlier (and very clever!) var call = Function.prototype.call.bind(Function.prototype.call); and by direct analogy: var ap

Re: On "I got 99 problems and JavaScript syntax ain't one"

Since you're assuming you can initialize and grab stuff before your context is corrupted, what's wrong with Lasse's earlier (and very clever!) var call = Function.prototype.call.bind(Function.prototype.call); and by direct analogy: var apply = Function.prototype.call.bind(Function.protot

Re: On "I got 99 problems and JavaScript syntax ain't one"

Le 05/10/2011 10:17, Lasse Reichstein a écrit : On Tue, Oct 4, 2011 at 6:19 PM, David Bruant > wrote: I sent a message here explaining the necessity of a syntax construct for a reliable bind [1]. There is a need to investingate (one reply was very close

Re: On "I got 99 problems and JavaScript syntax ain't one"

On Tue, Oct 4, 2011 at 6:19 PM, David Bruant wrote: > ** > I sent a message here explaining the necessity of a syntax construct for a > reliable bind [1]. There is a need to investingate (one reply was very close > from a solution) to make sure that such a thing is not possible in pure ES5 > (wit

Re: traits feedback

Thanks for the feedback, John. I have to admit that at first I was also taken aback by the apparent complexity of the "syntax for efficient traits" strawman. Traits have many knobs, and require a lot of syntax to turn these knobs. Regardless of whether you'd want nice declarative syntax for trait