On Apr 21, 2011, at 6:11 AM, Geoffrey Sneddon wrote:
> On 18/03/11 20:05, Brendan Eich wrote:
>> ...
>> 8. Else goto one of the earlier steps, possibly adjusting specs and impls
>> based on feedback and uptake.
>>
>> This is *not* going to be "quick".
On Apr 22, 2011, at 3:34 PM, Claus Reinke wrote:
>
> Perhaps you should have used 'catch' instead of 'with' for
> your example - the combination of
> - implementations allowing FunctionDeclaration as statement
> - implementations differ in how such FunctionDeclarationsare hoisted
>
On Apr 27, 2011, at 2:09 PM, Sean Eagan wrote:
> As explained
> before, the existing ES5 semantics would cause the proxy's
> "getPropertyDescriptor" trap to be called thus obtaining any "getter"
> / "setter" that the proxy wants. The |this| binding of this "getter"
> / "setter" will then be set t
Thanks to Waldemar again for his notes. These plus my memory were the basis of
all my recent edits. I moved strawmen to proposals and left forwarding pages
(in case of external links). In the course of this, I improved and tested some
of the self-hosted specs, e.g. Number.isInteger. Anyone motiv
Good catch, I fixed. Thanks,
/be
On Apr 28, 2011, at 4:20 AM, David Bruant wrote:
> Hi,
>
> This is purely an editing issue, but for String.prototype.repeat, Number is
> passed as an argument while String isn't.
> Following the idea of correctness that Mark Miller used in [1], I propose to
>
On Apr 29, 2011, at 1:08 PM, Axel Rauschmayer wrote:
> Would it make sense to standardize more exception/error types, for example to
> add a MissingParameterError in ES.next?
No proposal yet for demanding actual parameter count match formal, so this
would not be used.
It can't be used from bui
On May 6, 2011, at 5:04 PM, Peter Michaux wrote:
> The only possible category is "be a better language" but the arrow
> syntax won't make JavaScript a better language for complex
> applications or libraries in comparison to any other kind of
> JavaScript code.
Usability is always on the top three
On May 6, 2011, at 11:22 PM, Peter Michaux wrote:
> On Fri, May 6, 2011 at 11:05 PM, Andrew Dupont
> wrote:
>
>> I don't want to get too deep into matters of taste, but I do think the
>> current syntax is annoyingly verbose for passing lambdas as arguments in
>> other functions. The fact that
On May 7, 2011, at 1:37 AM, Jorge wrote:
> But if I wanted a shorter syntax, I would no doubt choose ruby blocks'
> syntax, it's even shorter yet and it's familiar already to millions of
> programmers.
Ruby and Smalltalk before it had blocks for most of their usable lives. JS does
not. Having
On May 9, 2011, at 2:21 AM, Irakli Gozalishvili wrote:
> On Monday, 2011-05-09 at 11:02 , Kyle Simpson wrote:
>
>> Isn't that the spirit of what => would give us?
>>
> Yes and this case makes following example extremely confusing:
>
> MyObject.prototype.bar = #(x) { this.bar = x }
>
> Is this i
You are ignoring =>.
Please do read the strawman, such as it is. Edits coming soon to clarify.
/be
On May 7, 2011, at 11:48 PM, Garrett Smith wrote:
> On 5/7/11, Faisal Vali wrote:
>>> "Kyle Simpson"
>>> Date: Sat, 7 May 2011 21:58:32 -0500
>>> Subject: Re: arrow syntax unnecessary and the id
favor of -> ?
>
> Brendan, you liked it. What has happened ?
>
> <https://mail.mozilla.org/pipermail/es-discuss/2008-November/008216.html>
> --
> Jorge.
>
> Begin forwarded message:
>
>> From: Brendan Eich
>> Date: 30 de noviembre de 2008 07:30:14 GMT+0
On May 9, 2011, at 2:21 AM, Irakli Gozalishvili wrote:
> On Monday, 2011-05-09 at 11:02 , Kyle Simpson wrote:
>
>> Isn't that the spirit of what => would give us?
>>
> Yes and this case makes following example extremely confusing:
>
> MyObject.prototype.bar = #(x) { this.bar = x }
>
> Is this i
On May 10, 2011, at 4:27 PM, Isaac Schlueter wrote:
> On Tue, May 10, 2011 at 16:22, Oliver Hunt wrote:
>> \ is a much more common lambda symbol in many languages, and i'm not sure
>> what the ambiguity would be in \{...} or \(...){...}.
>
> \(a,b,c) { a + b * c }
>
> That's cute.
Oliver stil
On May 10, 2011, at 4:31 PM, Axel Rauschmayer wrote:
> Quoting Andrew Dupont:
>
>> (b) the ->/=> distinction is, I think, too subtle. Rebinding dramatically
>> changes the meaning of the function, so I'd prefer if the notation
>> guaranteed that a user couldn't gloss over that by mistaking -> f
On May 10, 2011, at 4:53 PM, Douglas Crockford wrote:
> The language has difficult syntax due to its C/Fortran heritage which daily
> makes the use of the language unnecessarily painful. I would like to repair
> the traps and confusions so that the language can be practiced more
> productively. Br
See also
http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes and especially
http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes#a_note_regarding_security
which date from ES4, and
http://wiki.ecmascript.org/doku.php?id=strawman:encapsulated_hashcodes
which needs updating.
/be
On
On May 11, 2011, at 8:52 AM, Claus Reinke wrote:
>> ECMAScript has a large set of problems. I think that the fact that
>> 'function' has eight letters is at the bottom of the priority list.
>
> - fixing ECMAScript's oddities would be worth a language revision,
> even without adding anything n
On May 11, 2011, at 9:12 AM, Brendan Eich wrote:
> On May 11, 2011, at 8:52 AM, Claus Reinke wrote:
>> More concise function syntax is important, as long as the deeper
>> issues get resolved, too.
>
> What deeper issue beyond |this| binding (lexical, dynamic, soft,
On May 11, 2011, at 9:32 AM, David Herman wrote:
> I agree. But I am sympathetic to Doug's concern about further overloading the
> curly-brace syntax.
That is purely a syntactic problem. More soon, tomorrow I hope.
/be
___
es-discuss mailing list
es-d
On May 11, 2011, at 9:39 AM, Douglas Crockford wrote:
> We have observed that one of the world's best capability theorists and
> practitioners, intending to to write solid code with capability discipline,
> was tripped up by completion value leakage. I think it is a real problem, and
> I think
On May 11, 2011, at 9:53 AM, Brendan Eich wrote:
> 1. E is an expression language. JS would need opt-in syntax to make a
> sub-language (e.g. arrow function bodies) an expression language, and you'd
> still have plausible objections that with statements on the outside and
> e
On May 11, 2011, at 11:26 AM, Jorge wrote:
> On 11/05/2011, at 18:53, Brendan Eich wrote:
>
>> (...)
>>
>> 3c. The use of {| (possibly with space in between) is an unambiguous
>> extension, but formal parameters inside |...| delimiters creates a problem
>
On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
> So you want to do
> if (map.has(bar))
> wiffle = map.get(bar)
>
> or some such?
>
> The problem here is that you can't guarantee that GC won't happen between
> those two calls, and therefore you could still end up getting undefined in
> resp
On May 11, 2011, at 1:04 PM, Oliver Hunt wrote:
> On May 11, 2011, at 12:54 PM, Brendan Eich wrote:
>
>> On May 11, 2011, at 12:44 PM, Oliver Hunt wrote:
>>
>>> So you want to do
>>> if (map.has(bar))
>>> wiffle = map.get(bar)
>>>
>>
See http://wiki.ecmascript.org/doku.php?id=harmony:egal -- I took the liberty
of renaming 'eq' to 'is' and I made the operator idea from the November TC39
meeting concrete.
Note that egal as an ''is' operator, with 'isnt' as the not-egal operator,
differs from CoffeeScript's 'is' and 'isn't, wh
On May 11, 2011, at 4:23 PM, Mark S. Miller wrote:
> On Wed, May 11, 2011 at 2:15 PM, Brendan Eich wrote:
> See http://wiki.ecmascript.org/doku.php?id=harmony:egal -- I took the liberty
> of renaming 'eq' to 'is' and I made the operator idea from the November TC39
On May 12, 2011, at 7:42 AM, Claus Reinke wrote:
ECMAScript has a large set of problems. ..
>>> - fixing ECMAScript's oddities would be worth a languagerevision, even
>>> without adding anything new
>> This is a mistake. The Web does not permit "stop the world and fix all known
>> bugs
On May 11, 2011, at 4:01 PM, Allen Wirfs-Brock wrote:
> On May 11, 2011, at 9:53 AM, Brendan Eich wrote:
>
>> ...
>>
>> 3. Blocks as implicitly quoted code could be like zero-argument lambdas,
>> with break, continue, return, |this|, and |arguments| referred to
On May 12, 2011, at 11:27 AM, Claus Reinke wrote:
> Would it be possible for you to follow basic netiquette?
I'm trying. Are you? We've been around this block before.
Either there is substance or there isn't. If there's no substantial proposal to
discuss, then many paragraphs of generalizations
On May 12, 2011, at 10:55 AM, Brendan Eich wrote:
> Ruby is far from simple, btw. Check out
>
> http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby
>
> and the wikipedia page it references.
>
> Looks like Proc.new but not lambda can return from it
On May 12, 2011, at 1:06 PM, Brendan Eich wrote:
> On May 12, 2011, at 10:55 AM, Brendan Eich wrote:
>
>> Ruby is far from simple, btw. Check out
>>
>> http://samdanielson.com/2007/3/19/proc-new-vs-lambda-in-ruby
>>
>> and the wikipedia page it references
d I know
> that casual subjective opinions are not necessarily welcomed here, but that's
> my tuppence all the same.
>
> If this mentality is anathema to the group, and if anyone is open to discuss
> this strategy lest we pollute this list, feel free to get in touch
>
>
On May 7, 2011, at 2:39 PM, Claus Reinke wrote:
>> Consider this: w = (x)->y || z
>> That code is not obvious at all. Which of these would it be?
>> 1: w = function (x) { return y } || z
>> 2: w = function (x) { return y || z }
>> It seems to me that there must be some sort of delineation around
On May 13, 2011, at 2:52 PM, Brendan Eich wrote:
> One might be tempted to make an unparenthesized (on the outside) function
> expression with an unparenthesized expression body be a low-precedence
> expression (say, AssignmentExpression), but then it can't be used as the
>
On May 13, 2011, at 11:25 PM, Brendan Eich wrote:
> I'll update
> http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax to
> include an ES5 grammar patch.
Done: http://wiki.ecmascript.org/doku.php?id=strawman:arrow_function_syntax,
specifically
http://wiki.
On May 14, 2011, at 11:59 PM, Mark S. Miller wrote:
> On Sat, May 14, 2011 at 11:57 PM, Erik Corry wrote:
>
> On May 15, 2011 2:55 AM, "Boris Zbarsky" wrote:
> >
> > On 5/14/11 6:37 PM, Oliver Hunt wrote:
> >>
> >> Can you provide a use case where you have an object key as the usual
> >> progr
On May 15, 2011, at 8:14 AM, Dmitry A. Soshnikov wrote:
> // Use # to freeze and join to nearest relevant closure
> function return_pure() {
>
>
> return #(a)
> -> a * a;
>
> }
>
>
> let p = return_pure
> ()
> ,
> q = return_pure
> ()
> ;
> assert
> (p === q);
> So, ES3 joined-objects
On May 14, 2011, at 11:33 PM, Brendan Eich wrote:
> Grammar Changes
> Change all uses of AssignmentExpression outside of the Expression sub-grammar
> to InitialExpression:
>
> ...
> ArrowFunctionExpression :
> FormalParametersOpt Arrow [lookahead ∉ {
On May 14, 2011, at 6:06 PM, Rick Waldron wrote:
> Boris,
>
> Would you mind sharing a piece of working code (as in, runs in the latest
> Firefox Nightly) that demonstrates your example in a real world scenario?
> This would be greatly appreciated
javascript:k = {}; v = "hi"; w = WeakMap(); w
ith strong
references". Using Map by default is going to make leaks in the real world,
guaranteed. Using WeakMap when in doubt will cost a bit more but avoid leaks.
/be
>
> Either way, thanks again!
>
> Rick
>
>
> On Sun, May 15, 2011 at 2:02 PM, Brendan Eich wrote:
eached, then depending on the decision, rewrite
the AST (e.g., to make a labeled statement in a block instead of an object
initializer).
/be
On May 15, 2011, at 10:26 AM, Brendan Eich wrote:
> On May 14, 2011, at 11:33 PM, Brendan Eich wrote:
>
>> Grammar Changes
To enable unpar
On May 15, 2011, at 11:55 AM, Dmitry A. Soshnikov wrote:
> Oh, my misunderstanding then. Then I just incorrectly treated yours
>
> assert(p === q);
This was from
// Use # to freeze and join to nearest relevant closure
function return_pure() {
return #(a) -> a * a;
}
let p = return_pure(),
On May 15, 2011, at 11:56 AM, Dmitry A. Soshnikov wrote:
> Oh, and just a small note -- perhaps there's a sense to put a comment near
> each line to what result the expression evaluates in your examples, e.g.
>
> asset(p === q); // true (or false?)
That is confusing and pointless. I meant what
On May 15, 2011, at 1:09 PM, Axel Rauschmayer wrote:
> Sorry for bringing this up again, but I don’t think this particular question
> has been answered yet:
>
> (1) I would prefer non-method functions not to have a binding for |this| at
> all.
How do you define "non-method"?
It would make an
On May 15, 2011, at 1:49 PM, Faisal Vali wrote:
> Could I trouble you to confirm or clarify the semantics of the
> following constructs*:
>
> let f = -> -> 3; // well-formed?
> let x = f()(); // x is equal to 3 right?
Sure, unambiguous. Same as in CoffeeScript:
coffee> f = -> -> 3;
[Function]
On May 15, 2011, at 1:52 PM, Dmitry A. Soshnikov wrote:
>> Each evaluation of a given function expression gives a fresh object in JS
>> today. WIth joining as Mark proposed at
>>
>> http://wiki.ecmascript.org/doku.php?id=strawman:const_functions#joining
>
> Got it. Though it still seems to me a
On May 15, 2011, at 1:54 PM, Dmitry A. Soshnikov wrote:
>> See last reply for more on joining. It occurs to me you thought scope chain
>> varying in the context of a pure hash-rocket such as #->42 means that
>> function cannot be joined, but since it is pure, it need not entrain its
>> scope ch
On May 15, 2011, at 2:36 PM, Axel Rauschmayer wrote:
> Caveat: I am aware that what I’m suggesting might clash too hardly with
> current semantics (how to handle invocation, apply(), call(), etc.), but I am
> interested in the arguments against it.
The strawman contains bits of rationale, pleas
On May 15, 2011, at 3:48 PM, Oliver Hunt wrote:
> On May 15, 2011, at 3:47 PM, Boris Zbarsky wrote:
>
>> On 5/15/11 2:20 PM, Rick Waldron wrote:
>>> Thanks Brendan, I was looking for something that was representative of
>>> Boris's use-case
>>
>> A typical example is an extension wanting to asso
On May 15, 2011, at 3:41 PM, Sam Tobin-Hochstadt wrote:
> On Sun, May 15, 2011 at 6:31 PM, Allen Wirfs-Brock
> wrote:
>>
>> On May 14, 2011, at 5:03 PM, Oliver Hunt wrote:
>>
>>> I suspect i did suggest WeakMap but I think I misunderstood the proposal.
>>> I felt the goal was to prevent the k
http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
This looks pretty good at a glance, but it's a lot, and it's new.
I have to say this reminds me of ES4 classes. That's neither bad nor good, but
it's not just superficial, as far as I can tell (and I was r
On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
>
> This looks pretty good at a glance, but it's a lot, and it's new.
Looking closer, I have to say something non-nit-picky that l
On May 15, 2011, at 11:53 PM, Erik Corry wrote:
> 2011/5/16 Brendan Eich :
>> This is a good point too. Not sure we've considered a value -> value map
>> carefully yet.
>
> A value->anything map is pretty easy to do with a normal JS object.
>
> fun
On May 15, 2011, at 11:55 PM, Erik Corry wrote:
> 2011/5/16 Brendan Eich :
>> On May 15, 2011, at 3:48 PM, Oliver Hunt wrote:
>>
>>> On May 15, 2011, at 3:47 PM, Boris Zbarsky wrote:
>>>
>>>> On 5/15/11 2:20 PM, Rick Waldron wrote:
>>>&
On May 16, 2011, at 12:01 AM, Brendan Eich wrote:
> On May 15, 2011, at 11:55 PM, Erik Corry wrote:
>
>> 2011/5/16 Brendan Eich :
>>> Not if the object is frozen.
>>
>> That shouldn't prevent you adding private names. See earlier message
>> in this
On May 16, 2011, at 12:08 AM, Erik Corry wrote:
> 2011/5/16 Brendan Eich :
>> On May 15, 2011, at 11:55 PM, Erik Corry wrote:
>>
>>> 2011/5/16 Brendan Eich :
>>>> On May 15, 2011, at 3:48 PM, Oliver Hunt wrote:
>>>>
>>>>> On May 1
On May 16, 2011, at 12:11 AM, Erik Corry wrote:
> 2011/5/15 Brendan Eich :
>> Besides attaching metadata, weak maps are important for remembering the
>> wrapper or membrane for a given (frozen or not, built-in or "host", not to
>> be mutated) object identity. Mark
On May 16, 2011, at 12:18 AM, Erik Corry wrote:
> 2011/5/16 Brendan Eich :
>> On May 16, 2011, at 12:01 AM, Brendan Eich wrote:
>>
>>> On May 15, 2011, at 11:55 PM, Erik Corry wrote:
>>>
>>>> 2011/5/16 Brendan Eich :
>>>>> Not if
On May 16, 2011, at 12:10 AM, Erik Corry wrote:
> 2011/5/16 Brendan Eich :
>> On May 15, 2011, at 11:53 PM, Erik Corry wrote:
>>
>>> 2011/5/16 Brendan Eich :
>>>> This is a good point too. Not sure we've considered a value -> value map
>>&
On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:
> On 16.05.2011 10:49, Brendan Eich wrote:
>>
>> On May 15, 2011, at 10:01 PM, Brendan Eich wrote:
>>
>>> http://wiki.ecmascript.org/doku.php?id=strawman:classes_with_trait_composition#open_issues
>&g
On May 16, 2011, at 12:43 AM, Erik Corry wrote:
>>> Elided for clarity :-) It can be implemented with private names or
>>> WeakMaps.
>>
>> Oh, ok -- you wrote "normal JS object" and that seemed to preclude new stuff.
>>
>> Yes, we can make a value -> value map as a library abstraction, but it's
On May 16, 2011, at 12:47 AM, Erik Corry wrote:
> I think the objects used as keys in weak maps need to be somehow
> annotated with this information so that the GC can clean up the weak
> maps when the keys die. This means that if you take an object that is
> frozen and use it as a key in a weak
On May 16, 2011, at 1:52 AM, Erik Corry wrote:
> My question was, do the use cases have both the GC of the map and the
> key triggering the GC of the value or is the GC of the key the
> important one and GC of the map not that common/important etc.
I'm not sure, we will have to measure to give a
s all beside the point.
Frozen objects are not observably extensible. I argued that we want an
implementation option to put their shallowly-frozen state (values at least) in
read-only memory. I have not seen anything like an argument why this option
should be forbidden.
/be
>
> --Oliver
On May 16, 2011, at 11:40 AM, Brendan Eich wrote:
> Frozen objects are not observably extensible. I argued that we want an
> implementation option to put their shallowly-frozen state (values at least)
> in read-only memory. I have not seen anything like an argument why this
> opti
On May 16, 2011, at 11:30 AM, Erik Corry wrote:
> 2011/5/16 Andreas Gal :
>>
>> Even if you want to store weak-map specific meta data per object, nobody
>> would store that directly in the object. Thats needlessly cruel on the cache
>> since >>99.9% of objects never end up in a weak map. Instea
On May 16, 2011, at 1:15 PM, Oliver Hunt wrote:
> On May 16, 2011, at 1:07 PM, Brendan Eich wrote:
>> WeakMaps satisfy this more general non-enumerable object-keyed cache
>> use-case well, too -- at least as far as I can tell. We'll be building on
>> the Firefox nigh
On May 16, 2011, at 1:36 PM, Axel Rauschmayer wrote:
> Thanks for explaining the details. With "temporary result", I meant what you
> call "object reference". Similar to Common Lisp places (setf etc.), I
> suppose. If you use the conditional operator, you can force the dereferencing
> of an obj
On May 16, 2011, at 2:46 PM, Hudson, Rick wrote:
> This is all a bit off topic but performance does matter and folks seem to be
> underestimating the wealth of community knowledge that exists in this area.
Who underestimates?
A bunch of us are aware of all this. Allen certainly knows all about
On May 16, 2011, at 2:07 PM, Boris Zbarsky wrote:
> That said, defining JS strings and DOMString differently seems like a recipe
> for serious author confusion (e.g. actually using JS strings as the DOMString
> binding in ES might be lossy, assigning from JS strings to DOMString might be
> loss
On May 16, 2011, at 5:18 PM, Allen Wirfs-Brock wrote:
> On May 16, 2011, at 5:06 PM, Brendan Eich wrote:
>
>> On May 16, 2011, at 2:07 PM, Boris Zbarsky wrote:
>>
>>> That said, defining JS strings and DOMString differently seems like a
>>> recipe for ser
On May 16, 2011, at 7:55 PM, Peter Michaux wrote:
> On Mon, May 9, 2011 at 6:02 PM, Brendan Eich wrote:
>
>> Yes, and we could add call/cc to make (some) compiler writers even happier.
>> But users would shoot off all their toes with this footgun, and some
>> im
On May 16, 2011, at 8:13 PM, Allen Wirfs-Brock wrote:
> I think it does. In another reply I also mentioned the possibility of tagging
> in a JS visible manner strings that have gone through a known encoding
> process.
Saw that, seems helpful. Want to spec it?
> If the strings you are combinin
On May 17, 2011, at 10:22 AM, Boris Zbarsky wrote:
> Yes. And right now that's how it works and actual JS authors typically don't
> have to worry about encoding issues. I don't agree with Allen's claim that
> "in the long run JS in the browser is going to have to be able to deal with
> arbitr
On May 17, 2011, at 10:37 AM, Boris Zbarsky wrote:
> On 5/17/11 1:27 PM, Brendan Eich wrote:
>> On May 17, 2011, at 10:22 AM, Boris Zbarsky wrote:
>>
>>> Yes. And right now that's how it works and actual JS authors typically
>>> don't have to worry
On May 17, 2011, at 10:43 AM, Boris Zbarsky wrote:
> On 5/17/11 1:40 PM, Brendan Eich wrote:
>> Where do you read "forcing"? Not in the words you cited.
>
> In the substance of having strings in different encodings around at the same
> time. If that doesn'
On May 17, 2011, at 10:47 AM, Brendan Eich wrote:
> On May 17, 2011, at 10:43 AM, Boris Zbarsky wrote:
>
>> On 5/17/11 1:40 PM, Brendan Eich wrote:
>>> Where do you read "forcing"? Not in the words you cited.
>>
>> In the substance of having string
On May 17, 2011, at 5:04 PM, Kyle Simpson wrote:
> Regarding the -> and => syntax, I just want to throw out one other concern
> that I hope is taken into account, not only now, but for the future: I really
> hope that we don't get to the point where we start adding functionality to
> that style
On May 18, 2011, at 6:46 AM, Sam Tobin-Hochstadt wrote:
> On Wed, May 18, 2011 at 2:59 AM, Luke Hoban wrote:
That sort of pattern certainly can be repeated if push comes to shove.
But I believe doing so is far inferior to dedicated, first-class
syntactical support to make the se
On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote:
> Proxies do coerce all property names to strings, e.g. proxy[obj] will trigger
> the 'get' trap with 'obj' coerced to a String. This is not actually enforced
> by the proxy spec, but rather by ES5 (e.g. [[Get]] assumes that its argument
> P is
On May 18, 2011, at 7:45 AM, Mark S. Miller wrote:
> On Wed, May 18, 2011 at 7:38 AM, Brendan Eich wrote:
> On May 18, 2011, at 7:28 AM, Tom Van Cutsem wrote:
>
> > Proxies do coerce all property names to strings, e.g. proxy[obj] will
> > trigger the 'get' trap
I'm working on a block-as-better-function proposal, essentially an alternative
to arrow-function-syntax even though unlike the latter, the former has new
semantics.
One of the insights from Allen and Mark, which is kind of obvious to Rubyists,
is that blocks as lightweight functions usable for
On May 18, 2011, at 9:10 AM, Allen Wirfs-Brock wrote:
> On May 18, 2011, at 12:41 AM, Dmitry A. Soshnikov wrote:
>
>> On 18.05.2011 6:50, Allen Wirfs-Brock wrote:
>>>
>>> We had so much fun with feedback on my Unicode proposal I just have open
>>> another one up for list feed back:
>>>
>>> An
On May 18, 2011, at 9:25 AM, Dean Landolt wrote:
> I think the argument for ease of static analysis applies just as well to
> human analysis (after all, our wetware makes for a poor interpreter). But I
> think the counter-argument is more compelling -- this is yet another
> construct our *tooli
On May 18, 2011, at 9:47 AM, Allen Wirfs-Brock wrote:
> I suspect that to most JS programmers the UML open triangle generalization
> arrow head is at least as relevant a precedent as any type theory uses.
I will take that bet. UML, ho ho! Maybe enterprise Java heads...
> In other words,the re
On May 18, 2011, at 9:51 AM, Brendan Eich wrote:
> On May 18, 2011, at 9:47 AM, Allen Wirfs-Brock wrote:
>
>> In the end, these are just symbols and JS programmer are just going to have
>> to learn their meaning. Existing conventions, if they exist, and analogous
&g
On May 18, 2011, at 10:07 AM, Mark S. Miller wrote:
> I made my peace with <| when Allen pointed out that the object on the left
> points at the object on the right. Flipping it around loses that mnemonic.
> This "points at" intuition should be independent of any prior exposure to UML.
Do you m
On May 18, 2011, at 10:30 AM, Allen Wirfs-Brock wrote:
> On May 18, 2011, at 9:52 AM, Brendan Eich wrote:
>
>> On May 18, 2011, at 9:51 AM, Brendan Eich wrote:
>>
>>> On May 18, 2011, at 9:47 AM, Allen Wirfs-Brock wrote:
>>>
>>>> In the end, th
On May 18, 2011, at 10:58 AM, Bob Nystrom wrote:
> On Mon, May 16, 2011 at 8:02 AM, Brendan Eich wrote:
> On May 16, 2011, at 4:54 AM, Dmitry A. Soshnikov wrote:
>> Regarding `new` keyword for the constructor (aka initializer), after all, it
>> als may be OK. E.g. Ruby uses `n
The rationale for the arrow pointing the way the proto-link points was also in
the very message Bob cited :-P.
"Triangle man, Triangle man
Triangle man hates particle man
They have a fight, Triangle wins
Triangle man"
(Some think this is about world religions, others say physics. I say OOP.)
/b
On May 18, 2011, at 5:57 PM, Bob Nystrom wrote:
> class Point {
> public x = 0, y = 0;
> }
>
> let p = new Point();
> p.x; // 0
This is pretty rare, in my experience. A hard case? If the constructor does set
x and y from parameters, then you have double-initialization. If some
properties are
On May 19, 2011, at 6:36 AM, Mark S. Miller wrote:
> 1) Starting from scratch, there's no problem engineering a VM to make
> objects-as-closures efficient, especially given the semi-static analysis that
> class proposal was designed to enable. However, JS VM implementors are not
> starting from
On May 19, 2011, at 2:42 AM, Lasse Reichstein wrote:
Hi Lasse.
> On Wed, 11 May 2011 02:44:30 +0200, Brendan Eich wrote:
>
>> I've mooted \ along with ƒ, etc. for a while. \ is bad for readability
>> because it's visually light, but worse, if we want named funct
On May 19, 2011, at 1:46 AM, Claus Reinke wrote:
>> Ok, final and most delicate part of the mission here: allow (v) -> {k: v}
>> and even -> {} to return objects, not make useless block statements.
> ..
>> Thanks to Doug for pushing on this idea. I believe that it is sound (still
>> to be forma
On May 18, 2011, at 3:46 PM, Waldemar Horwat wrote:
> On 05/16/11 11:11, Allen Wirfs-Brock wrote:
>> I tried to post a pointer to this strawman on this list a few weeks ago, but
>> apparently it didn't reach the list for some reason.
>>
>> Feed back would be appreciated:
>>
>> http://wiki.ecmas
On May 19, 2011, at 10:27 AM, Shawn Steele wrote:
>> The crucial win of Allen's proposal comes down the road, when someone in a
>> certain locale *can* do s.indexOf(nonBMPChar) and win.
> s.indexOf("\U+1"),
Ok, but "\U+..." does not work today.
> who cares that it ends up as UTF-16? You c
On May 19, 2011, at 10:44 AM, Bob Nystrom wrote:
> On Wed, May 18, 2011 at 6:29 PM, Brendan Eich wrote:
> On May 18, 2011, at 5:57 PM, Bob Nystrom wrote:
>
>> class Point {
>> public x = 0, y = 0;
>> }
>>
>> let p = new Point();
>> p.x; // 0
>
On May 19, 2011, at 11:02 AM, Bob Nystrom wrote:
> On Thu, May 19, 2011 at 10:50 AM, Brendan Eich wrote:
> Don't take this the wrong way ;-), but how many of those initializations were
> immediately overwritten by the constructor, unconditionally or even
> conditionall
On May 19, 2011, at 11:55 AM, Mark S. Miller wrote:
> I like Bob's "this.x" form best, especially when combined with your
> observation about default values.
That's great -- if we want to shorthand harder, we can consider .x for this.x
down the road.
> The reason I prefer "this.x" rather than
401 - 500 of 5389 matches
Mail list logo
