On Jul 8, 2011, at 4:27 PM, Luke Hoban wrote:
> I agree wholeheartedly with these. In fact, I’d go further on (2), and
> say “Anything that can be done declaratively can also be done
> imperatively, using ES5 syntax”.
>
> >>The problem here is that some new syntax cannot be fa
On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
> On Jul 8, 2011, at 3:49 PM, Allen Wirfs-Brock wrote:
>
>> 2) Anything that can be done declaratively can also be done imperatively.
>
> What's the imperative API for <| (which has the syntactic property that it
>
On Jul 8, 2011, at 2:58 PM, Brendan Eich wrote:
> On Jul 8, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
>
>> The current Harmony classes proposal
>> http://wiki.ecmascript.org/doku.php?id=harmony:classes includes the concept
>> of private instance members and syntax f
On Jul 8, 2011, at 5:53 PM, David Herman wrote:
> I think I still haven't fully grokked what <| means on array literals, but
> could it also be used to "subclass" Array? For example:
yes, it creates a new object that is an array instance ([[Class]]=='Array',
support the length constraints, etc.
On Jul 8, 2011, at 6:03 PM, Brendan Eich wrote:
> On Jul 8, 2011, at 5:48 PM, Allen Wirfs-Brock wrote:
>
>> On Jul 8, 2011, at 5:16 PM, Brendan Eich wrote:
>>
>>> What's the imperative API for <| (which has the syntactic property that it
>>> op
On Jul 9, 2011, at 9:45 AM, Brendan Eich wrote:
> On Jul 9, 2011, at 8:48 AM, Brendan Eich wrote:
>
>> See above, there is nothing novel or evil in isName or isArray (another
>> example) isGenerator.
>
> Also the Proxy.isTrapping, which in recent threads has been proposed to be
> renamed to P
On Jul 9, 2011, at 1:43 PM, Brendan Eich wrote:
> On Jul 9, 2011, at 11:19 AM, Allen Wirfs-Brock wrote:
>
>> A consideration here is that whatever conventions we follow sets a precedent
>> for user written code. I don't think we want to encourage the addition of
On Jul 9, 2011, at 5:02 PM, Brendan Eich wrote:
> On Jul 9, 2011, at 4:32 PM, Allen Wirfs-Brock wrote:
>
>> On Jul 9, 2011, at 1:43 PM, Brendan Eich wrote:
>
>> ... However, if that isn't your concern (and my perspective is that in most
>> cases it shouldn'
On Jul 10, 2011, at 10:23 AM, Brendan Eich wrote:
> On Jul 10, 2011, at 10:18 AM, Rick Waldron wrote:
>
>> The more I think about it, I still can't come up with any really exciting
>> use cases where Array.of would outshine anything that already exists. I say
>> strike it from the wishlist.
>
> On Jul 9, 2011, at 7:22 PM, Brendan Eich wrote:
>
>> On Jul 9, 2011, at 5:02 PM, Allen Wirfs-Brock wrote:
...
>> 1) stratification - Proxy.isProxy is an example
>> 2) It is impossible or inconvenient to add the classification interface to
>> the appropriate ins
On Jul 10, 2011, at 10:32 AM, Allen Wirfs-Brock wrote:
>
> Yes, if you actually need to pass Array.of as a function argument. Of course
> if we have block lambdas you could just say:
>
> hof({|a|[a]})
> instead of
> hof(Array.of)
actually the above aren
On Jul 10, 2011, at 4:01 PM, Brendan Eich wrote:
> On Jul 10, 2011, at 3:54 PM, Brendan Eich wrote:
>
>> On Jul 10, 2011, at 3:02 PM, David Herman wrote:
>>
> I'm not sure what Array.prototype methods would or wouldn't work on
> instances of SubArray.
All of them. They are
On Jul 10, 2011, at 12:09 PM, Dmitry A. Soshnikov wrote:
> And by the way, an efficient `Array.prototype.unique` also would be nice to
> have, since in JS in general it's hard to implement it's efficiently (in
> lower level at least it will iterate faster).
>
> [1, 3, 2, 5, 5, 3].unique(); //
On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
> On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
>
>>>>
>>
>> Why not a non-writable,non-enumerable non-configurable data property on
>> Function.prototype.
>
> We're talking about isGene
On Jul 11, 2011, at 9:32 AM, Brendan Eich wrote:
> On Jul 11, 2011, at 9:25 AM, Allen Wirfs-Brock wrote:
>
>> On Jul 10, 2011, at 6:58 PM, Brendan Eich wrote:
>>
>>> On Jul 10, 2011, at 10:54 AM, Allen Wirfs-Brock wrote:
>>>
>>>> Why not a n
On Jul 11, 2011, at 10:41 AM, Brendan Eich wrote:
> On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:
>
>
>> Certainly there is no need to add any new globals to support a distinct
>> prototype for generator functions. Strictly speaking there wouldn't even
&
On Jul 11, 2011, at 11:50 AM, Claus Reinke wrote:
>>> How about rest and spread, or de-structuring? We are going to use non-eval
>>> detectability as a ECMAScript extension design criteria then maybe we do
>>> need a less ad-hoc scheme for feature detection. It wouldn't have to be
>>> all th
On Jul 11, 2011, at 4:19 PM, David Herman wrote:
>>> Adding a non-enumerable Array.prototype method seems doable to me, if the
>>> name is clear and not commonly used.
>>
>>
>> We can probably still add Array.prototoype.isArray if that would help to
>> establish the pattern. Document as being
On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:
> On Jul 11, 2011, at 12:40 PM, Allen Wirfs-Brock wrote:
>
>> isGenerator is essentially a value test rather than class-like
>> categorization. Methods work well for this because a method can dynamically
>> inspect t
On Jul 11, 2011, at 6:14 PM, Brendan Eich wrote:
> On Jul 11, 2011, at 5:29 PM, Allen Wirfs-Brock wrote:
>
>> However, for pure JS classification you want them to be duck-type
>> extensible. It is easy to add a new implementation for some category if the
>> catego
On Jul 11, 2011, at 7:31 PM, Allen Wirfs-Brock wrote:
>>>>
>>>
>>> Agreed, these are both cases where the category isn't user extensible.
>>> However, I think my statement holds for class-like categorization that are
>>> extensible.
>
On Jul 12, 2011, at 2:54 AM, Andreas Rossberg wrote:
> On 9 July 2011 17:48, Brendan Eich wrote:
>>
>
> Moreover, the distinction between names and proper
> objects will have to be deeply engrained in the spec, because it
> changes a fundamental mechanism of the language. Whereas WeakMaps are
On Jul 12, 2011, at 11:28 AM, David Herman wrote:
> No pejorative overtones intended. We just don't yet have any decent
> terminology for distinguishing the full ES.next front end from the
> backwards-compatible one.
In the working draft of the specification I'm using "extended code" to mean t
I've created a wiki page to host stable versions of the editors of the ES.next
(probably "ES6") specification. It is
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
The first working draft is also there in both MS office and PDF forms. It's
change log is:
• 5.1
(minor typo correction)
I've created a wiki page to host stable versions of the editor's draft of the
ES.next (probably "ES6") specification. It is
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
The first working draft is also there in both MS office and PDF forms. It
isProxy is definitely a meta-layer operation and you don't want it polluting
the application layer. However, when you doing proxy level meta programming I
can imagine various situations where you might need to determine whether or not
an object is a proxy. I think it should exist, but should e
Hate to start another cycle of this, but if (trapping) proxies can't be set to
[[Extensible]]: false, then they can't be used to fully emulate built-ins such
as Array. Why is there this restriction?
Allen
On Jul 13, 2011, at 1:23 AM, Tom Van Cutsem wrote:
> Perhaps Proxy.isProxy was used me
If you find a bug in a draft of the ES.next specification (
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ), the best
way to report it is to file a bug report at
https://bugs.ecmascript.org/enter_bug.cgi?product=Draft%20for%206th%20Edition .
If you think the bug needs disc
If you find a bug in a draft of the ES.next specification (
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts ), the best
way to report it is to file a bug report at
https://bugs.ecmascript.org/enter_bug.cgi?product=Draft%20for%206th%20Edition .
If you think the bug needs disc
Tom Van Cutsem wrote:
> Aren't arrays [[Extensible]]:true by default?
Yes, but any array object can be set to [[Extensible]]: false and the implicit
delete behavior defined in 15.4.5.1 for when length is set to a smaller value
still applies. To emulate that behavior at least the set/definePrope
On Jul 13, 2011, at 8:44 AM, David Herman wrote:
> Putting private properties on a proxy or storing it in a weak map are simple
> protocols you can use to keep track of proxies that you know about. You can
> hide or expose this information then without however many or few clients you
> like. I
(don't miss the second part of my response)
On Jul 14, 2011, at 5:21 AM, Andrew Oakley wrote:
> I'm not sure the Array.prototype.concat algorithm (§ 15.4.4.4) is quite
> right.
>
> As far as I can see the length property of the result (A) is not
> explicitly set anywhere in the algorithm so we a
On Jul 14, 2011, at 10:47 AM, Brendan Eich wrote:
> On Jul 14, 2011, at 10:38 AM, David Bruant wrote:
>
>>> In all the cases I can think of, where we want precisely the behavior of an
>>> array, why not just use an array?
>> Of course an array should be used. I think that the current question i
On Jul 14, 2011, at 10:39 AM, Brendan Eich wrote:
> On Jul 14, 2011, at 10:04 AM, Allen Wirfs-Brock wrote:
>
>> This appears to be a (possible) specification bug that first occurs in ES3
>> and which was not corrected in ES5.
>>
>> I appears in concat and push.
Also note that the current editor's draft
http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data has
some changes. Also there is some controversy about some of them
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12101
Something that isn't clear to me is which primordials ar
On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote:
> On Thu, Jul 14, 2011 at 12:19 PM, Allen Wirfs-Brock
> wrote:
> I think Mark and I are looking at Proxies from very different perspectives.
>
> Agreed.
>
>
> I want Proxies to to useful to create a perfect im
On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote:
> On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock
> wrote:
>
>
>>
>
> Implementations are free to add new built-in objects (see 4.3.28). Without
> any stated requirements for such objects you have no gua
On Jul 14, 2011, at 4:59 PM, Mark S. Miller wrote:
> On Thu, Jul 14, 2011 at 3:00 PM, Allen Wirfs-Brock
> wrote:
>
> On Jul 14, 2011, at 1:19 PM, Mark S. Miller wrote:
>
> Do you really think it makes sense to allow new properties to appear on
> non-extensible objects?
On Jul 14, 2011, at 9:30 PM, Jason Orendorff wrote:
> On Thu, Jul 14, 2011 at 2:46 PM, Mark S. Miller wrote:
>>
>
> Allen Wirfs-Brock write:
>> Something that isn't clear to me is which primordials are used
>> to set the [[Prototype]] of the generated obje
On Jul 14, 2011, at 10:38 PM, Jeff Walden wrote:
> Reraising this issue...
>
> To briefly repeat: Decode, called by decodeURI{,Component}, says to reject
> %ab%cd%ef sequences whose octets "[do] not contain a valid UTF-8 encoding of
> a Unicode code point". It appears browsers interpret this
On Jul 15, 2011, at 8:51 AM, Dean Landolt wrote:
>>
>> It's serialization.
>>
>> Or, it's a spec fiction to explain and codify the Web-visible effects
>> of serialization and deserialization without specifying a
>> serialization format.
>
>
> As such, it seem like this may be a poor specifica
On Jul 15, 2011, at 10:00 AM, Jonas Sicking wrote:
>
> Except that you don't want to do that for host objects. Trying to
> clone a File object by cloning its properties is going to give you an
> object which is a whole lot less useful as it wouldn't contain any of
> the file data. Once we define
On Jul 15, 2011, at 3:51 AM, Tom Van Cutsem wrote:
> Hi Allen,
>
> While proxies are definitely designed to emulate some of the peculiar
> behavior of host objects, that does not necessarily imply that proxies should
> be as powerful and free of restrictions as host objects. If any JS script c
On Jul 15, 2011, at 10:56 AM, Dean Landolt wrote:
>
>
> On Fri, Jul 15, 2011 at 1:30 PM, Allen Wirfs-Brock
> wrote:
>
> On Jul 15, 2011, at 10:00 AM, Jonas Sicking wrote:
> >
> > Except that you don't want to do that for host objects. T
...
>
> An
On Jul 15, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:
>
> On Jul 15, 2011, at 3:51 AM, Tom Van Cutsem wrote:
>
>> Hi Allen,
>>
>> While proxies are definitely designed to emulate some of the peculiar
>> behavior of host objects, that does not necessarily im
On Jul 15, 2011, at 12:47 PM, Brendan Eich wrote:
> On Jul 15, 2011, at 12:38 PM, Allen Wirfs-Brock wrote:
>
>> On Jul 15, 2011, at 11:16 AM, Allen Wirfs-Brock wrote:
>>
>>> But can't a Proxy based object do all sorts of nasty back channel stuff
>>> ev
On Jul 15, 2011, at 1:45 PM, Dean Landolt wrote:
>
>
> On Fri, Jul 15, 2011 at 2:50 PM, Allen Wirfs-Brock
> wrote:
>
>
> Okay, but what of the assertion itself? Must a cloned JS object must maintain
> its [[Prototype]]? I'm just curious as to why.
If it is a
I've recently been experimenting with coding both prototypal and class based
object definitions using the various syntactic forms that are currently on the
table. Something has emerged from that which has surprised me. I have never
been a big fan of the "extend" method that is provided by a nu
On Jul 18, 2011, at 10:51 AM, Jeff Walden wrote:
>
> Easiest fix is to just add the length-set to concat. For a quick ES5 erratum
> that seems best to me.
Yes, this needs to be in the errata.
>
> Removing all the RangeError stuff, and making array indexes just non-negative
> integers, wou
ately <+ can't be used.
Allen
>
> On Mon, Jul 18, 2011 at 12:32 PM, Allen Wirfs-Brock
> wrote:
>> I've recently been experimenting with coding both prototypal and class based
>> object definitions using the various syntactic forms that are currently on
>
On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote:
> Hawt.
>
> A bit rough in that LHS <& RHS mutates LHS, whereas LHS <| RHS is pure and
> produces a new object (which could be optimized to mutate RHS, note well!).
> Both <| and <& are operators, to support chaining. Would it be better for <&
On Jul 18, 2011, at 11:26 AM, Dmitry A. Soshnikov wrote:
> On 18.07.2011 21:32, Allen Wirfs-Brock wrote:
>>
>> I've recently been experimenting with coding both prototypal and class based
>> object definitions using the various syntactic forms that are currently on
On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
> On Mon, Jul 18, 2011 at 10:32 AM, Allen Wirfs-Brock
> wrote:
> > This is a nice declarative way to describe the per instance state but it
> > turns out it doesn't generalize very well to multiple levels of inher
On Jul 18, 2011, at 1:37 PM, Brendan Eich wrote:
> On Jul 18, 2011, at 12:16 PM, Allen Wirfs-Brock wrote:
>
>> On Jul 18, 2011, at 11:32 AM, Brendan Eich wrote:
>>
>>> Hawt.
>>>
>>> A bit rough in that LHS <& RHS mutates LHS, whereas LHS
On Jul 18, 2011, at 4:50 PM, Bob Nystrom wrote:
>
>
> On Mon, Jul 18, 2011 at 3:40 PM, Allen Wirfs-Brock
> wrote:
>
> On Jul 18, 2011, at 1:05 PM, Bob Nystrom wrote:
>> 2. Familiar from other languages and it works about the same here as it does
>> in those
On Jul 18, 2011, at 4:59 PM, Brendan Eich wrote:
>
> Word on the street, from folks ranging the skill gamut, is that <|, <& and so
> on are Perl-ish line noise. We should consider alternatives, even if it means
> restricted productions.
As I've said in the past, I'm generally more in the COBO
On Jul 18, 2011, at 7:24 PM, Axel Rauschmayer wrote:
>> From: Allen Wirfs-Brock
>> Date: July 18, 2011 19:32:24 GMT+02:00
>> To: es-discuss
>> Subject: An "extend" operator is a natural companion to <|
>
>
> Definitely a nice dual to <|
>
Ok, I did a side-by-side comparisons of some alternatives.
Seehttp://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aspecification_drafts&cache=cache&media=harmony:protooperator_alternatives.pdf
The first column is by prototypal inheritance example using<| and <& from the
first message in
On Jul 19, 2011, at 10:50 AM, Bob Nystrom wrote:
> On Mon, Jul 18, 2011 at 6:50 PM, Allen Wirfs-Brock
> wrote:
> But if you were coming from a language where constructors (classes) were real
> objects with real methods that could reference this and which were inherited
> by
On Jul 19, 2011, at 11:56 AM, Luke Hoban wrote:
>>> Object.extend(src, dest)
>
>> This is certainly closest to paving the cowpath. Either via a built-in
>> module exporting 'extend', or as you suggest, directly on Object. The
>> Object.extend route is a bit harder to analyze, but not fatally s
On Jul 19, 2011, at 12:10 PM, Brendan Eich wrote:
> On Jul 19, 2011, at 11:39 AM, Allen Wirfs-Brock wrote:
>>
>
>
>> The third column uses Object.specialize and Object.extend calls instead of
>> <| and <&.
>>
>> Note that Object.create can
On Jul 19, 2011, at 11:16 AM, Brendan Eich wrote:
> On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
>>
>
>
>
>> // "private" before a section lets you declare private members on that
>> object.
>> private new:
>> health;
>
> Not sure we need 'new' there given lack of private prototype pr
On Jul 19, 2011, at 11:23 AM, Brendan Eich wrote:
> On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
>
>> // "new" lets you declare members on new instances. these would presumably be
>
>> // invoked on the new object before the constructor body is run.
>> new:
>> numAttacks = 0;
>> // decl
On Jul 19, 2011, at 3:45 PM, Brendan Eich wrote:
> On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:
>
>> Also, why ; instead of , like in object literals
>
> We've been over this before: because methods have braced bodies that should
> not require either
t32 length
restriction on arrays. It is https://bugs.ecmascript.org/show_bug.cgi?id=145
https://bugs.ecmascript.org/show_bug.cgi?id=146 is a bug against the initial
length conversion for non-array object in the array methods.
Allen
On Jul 18, 2011, at 2:02 PM, liorean wrote:
>> On
On Jul 22, 2011, at 4:28 PM, Jeff Walden wrote:
> On 07/22/2011 04:13 PM, Axel Rauschmayer wrote:
>> In strict-mode, "this" isn’t boxed in, say, String.prototype.* methods. But
>> I don’t know how/whether that reflects the spec.
>
> This is not quite precisely true. See the second algorithm in
On Jul 22, 2011, at 3:16 PM, Mike Shaver wrote:
> Which primitives have own properties? I thought even "str".length
> conceptually came from the prototype.
>
>
No, 15.5.5/15.5.5.1 says that each string object (ie, each string wrapper) has
its own "length" property.
Allen
__
I've posted the current working draft at the usual place:
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
Not a lot of new material. Mostly typos that were corrected and working
through bug reports from bugs.ecmascript.org.
Note that changes in this version are marked "Re
"ISO/IEC Directives, Part 2"
www.iec.ch/members_experts/refdocs/iec/Directives-Part2-Ed5.pdf
On Aug 3, 2011, at 12:07 PM, Mark S. Miller wrote:
> On Wed, Aug 3, 2011 at 12:00 PM, Allen Wirfs-Brock
> wrote:
> (I removed the script-coord recipient and added ES-discuss as
This is partially a followup to the thread: An "extend" operator is a natural
companion to <|
Several interesting ideas developed out of informal conversations during last
week's TC-39 meeting.
The first ideas concerns the <| operator. As currently defined at
http://wiki.ecmascript.org/doku
On Aug 4, 2011, at 8:39 PM, Axel Rauschmayer wrote:
>> From: Allen Wirfs-Brock
>> However, as current specified the [[Prototype]] of bar.prototype will be
>> Object.prototype. In other words, bar inherits from foo but bar.prototype
>> doesn't inherit from foo.pr
On Aug 5, 2011, at 7:46 AM, Brendan Eich wrote:
> On Aug 4, 2011, at 11:00 PM, Allen Wirfs-Brock wrote:
>
>> On Aug 4, 2011, at 8:39 PM, Axel Rauschmayer wrote:
>>
>>>> Another idea was an alternative way to express the "extend" operator for
>>&g
On Aug 5, 2011, at 12:14 PM, Brendan Eich wrote:
> On Aug 5, 2011, at 9:32 AM, Allen Wirfs-Brock wrote:
>>>> I did something similar in my first go at this, but there is a problem...
>>>
>>> Right, the desugaring from class syntax is fragile and error-prone.
On Aug 8, 2011, at 3:39 AM, Andreas Rossberg wrote:
> On 4 August 2011 22:57, Allen Wirfs-Brock wrote:
>> Using these two new ideas and other active object literal enhancement
>> proposals it is pretty easy to compose a class-like declaration. For
>> example the Skinned
On Aug 5, 2011, at 4:15 PM, Bob Nystrom wrote:
>
>
> On Fri, Aug 5, 2011 at 3:29 PM, Allen Wirfs-Brock
> wrote:
> I think the Class function I suggest above could be an answer. But exploring
> this was my motivation in writing a significant amount of code using my
> p
On Aug 8, 2011, at 1:42 PM, Brendan Eich wrote:
> On Aug 5, 2011, at 3:29 PM, Allen Wirfs-Brock wrote:
>>
>>
>> I think hoisting classes may be problematic anyway.
>
> That would be surprising, if true, since classes are sugar for prototypal
> inheritance b
On Aug 8, 2011, at 9:24 PM, Brendan Eich wrote:
> On Aug 8, 2011, at 3:14 PM, Allen Wirfs-Brock wrote:
>
>> Let me try a more carefully constructed example:
>>
>> class First() {
>> class:
>> partner = (new Second).getPartner();
>
> Sure, this isn
On Aug 9, 2011, at 1:18 AM, Claus Reinke wrote:
>> The name resolution rules we agreed to permit mutually recursive
>> functions without hoisting (or you could view those rules as hoisting
>> everything):
>>
>> let f1 = function() {f2()};
>> let f2 = function() {f1()};
>> f1(); //happily recurs
On Aug 9, 2011, at 10:23 AM, Bob Nystrom wrote:
>
>
> On Mon, Aug 8, 2011 at 3:14 PM, Allen Wirfs-Brock
> wrote:
> ...
>
> I think it's reasonable to ask them to re-organize stuff a bit.
>
> class A {
> }
>
> class B {
> }
>
> A.b =
On Aug 9, 2011, at 1:29 AM, Claus Reinke wrote:
>> .. the key extensions I used in the collections experiment are:
>> ..
>> * the <| operator -- defines the [[Prototype]] of a literal
>> * the .{ operator -- extends the LHS object with properties from an object
>> literal
>
> How do these t
On Aug 8, 2011, at 10:40 PM, Brendan Eich wrote:
> On Aug 8, 2011, at 10:24 PM, Allen Wirfs-Brock wrote:
>
>>>> class superclass <| subclass () {
>>>> }
>>>
>>> That's so backward from other binding forms,
>> we don't really ha
In the fork of Narcissus at https://github.com/allenwb/narcissus I have
implemented various ES.next proposals (and a couple not yet proposals) for
enhanced object literal support. the extensions include:
* Concise Method Properties in Object Literals
* Comma Optional After Method and Accessor P
On Aug 15, 2011, at 5:42 PM, Zachary Carter wrote:
>
> It works for simple examples but has a ways to go before it can run
> the Smalltalk Collection classes. Also, AFAICT "transpilation" won't
> be able to fully support super references (namely, rebinding super
> using Object.defineMethod) but
correct, according to the spec, JDD's test should report true. What language
in the spec. lead you to think otherwise?
Allen
On Aug 16, 2011, at 9:12 AM, Luke Hoban wrote:
> My interpretation of these spec sections:
>
> (new bound) instanceof bound
> => (new Bar()) instanceof bound // bind's
I wrote up some comments on this draft. They can be found here:
https://docs.google.com/document/d/1OlDD5epjaXGBnb1jviD3tRuPsQmk0i72elkXb9gZQsc/edit?hl=en_US
On Aug 10, 2011, at 5:43 PM, Norbert Lindenberg wrote:
> I thought it would be useful to convert the results of our discussion on
> 201
On Aug 16, 2011, at 9:44 PM, John-David Dalton wrote:
> So @kitcambridge and I were talking spec and started trying to find in
> spec something that explains why something like:
>
> Array.prototype.reduce which is by default { [[Writable]]: true,
> [[Enumerable]]: false, [[Configurable]]: true
On Aug 17, 2011, at 9:14 AM, Juriy Zaytsev wrote:
> What do you mean by "clean scope"? All scope chains have at least global
> scope in them. Is that what "clean scope" chain would be — the one including
> global scope only? That's pretty much what `Function` constructor does.
or
(null,eval)
On Aug 17, 2011, at 10:37 AM, Rick Waldron wrote:
>
>
> On Wed, Aug 17, 2011 at 12:36 PM, Allen Wirfs-Brock
> wrote:
>
> On Aug 17, 2011, at 9:14 AM, Juriy Zaytsev wrote:
>
> > What do you mean by "clean scope"? All scope chains have at least global
&
On Aug 23, 2011, at 5:31 AM, Andreas Rossberg wrote:
> We are currently in the process of implementing block scoping for V8
> (http://wiki.ecmascript.org/doku.php?id=harmony:block_scoped_bindings).
The wiki page spec. is neither complete nor up to date so I wouldn't depend too
much on what it s
The rough convention we were following for ES5 was that Object.* functions that
were expected to be used in application layer code had short imperative names
like keys, create, freeze, etc. Functions that were expected to be primarily
used in meta layers of framework or other reflective purposes
On Aug 9, 2011, at 1:03 PM, Dmitry A. Soshnikov wrote:
>
> And what about this method Object.getMethods(...),
> Object.getMethodNames(...). Do we need it? I think it can be useful (since
> methods can be non-enumerable, and Object.keys(...) won't help, and after
> Object.getOwnPropertyNames(..
On Aug 9, 2011, at 2:05 PM, Dmitry A. Soshnikov wrote:
> On 24.08.2011 0:39, Allen Wirfs-Brock wrote:
>>
>>
>> I'm don't really see the that they are needed enough to build these in when
>> they can be synthesized pretty easily. What is the justification
On Aug 24, 2011, at 2:08 AM, Andreas Rossberg wrote:
>>
>
> Btw, we had this amusing discussion in July how to name the different
> language modes without stepping on people's toes. How about "classic",
> "strict", and "modern"?
>
The "modern" mode won't seem very modern twenty years from now.
On Aug 24, 2011, at 2:09 AM, Andreas Rossberg wrote:
> On 24 August 2011 01:07, Allen Wirfs-Brock wrote:
>> Also there can be real problems with exposing too much program metadata
>> directly to the application layer. I've had lots of experience with
>> Smalltalk e
On Aug 24, 2011, at 2:01 AM, Andreas Rossberg wrote:
> On 23 August 2011 19:14, Allen Wirfs-Brock wrote:
>>
>
> Oh, but that description does not cover Dave's exact example, which actually
> was
>
> { { let x; { var x } } }
>
> Here, the var is hoisted
Something we need to define for ES.next is how to compute the length property
value for functions whose formal parameter list includes "optional" and/or rest
parameters. (See
http://wiki.ecmascript.org/doku.php?id=harmony:parameter_default_values and
http://wiki.ecmascript.org/doku.php?id=harm
On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote:
> On 27 August 2011 00:34, Allen Wirfs-Brock wrote:
>> Something we need to define for ES.next is how to compute the length
>> property value for functions whose formal parameter list includes "optional"
>> an
On Aug 29, 2011, at 7:43 AM, Tom Van Cutsem wrote:
> (changed subject to fork off discussion on function proxies)
>
> 2011/8/29 Allen Wirfs-Brock
> On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote:
> > True, and actually, there are more issues with length & functio
On Aug 29, 2011, at 2:32 AM, Andreas Rossberg wrote:
> On 29 August 2011 01:36, Allen Wirfs-Brock wrote:
>> On Aug 27, 2011, at 6:12 AM, Andreas Rossberg wrote:
>>> True, and actually, there are more issues with length & function
>>> proxies. I don't have
On Aug 29, 2011, at 1:36 PM, Brendan Eich wrote:
>
> You can't use one integer-valued property to convey two meanings. F.length is
> either minimum non-default/rest parameters, or a count of non-rest
> parameters. I don't see a sane alternative. The count of non-rest parameters
> is not that
501 - 600 of 3206 matches
Mail list logo
