It looks like that in a number of these cases, what is being tested is the
number of declared arguments to the jquery Sizzle function which is a module
function for its selector engine. Very early versions of Sizzle seem to have
had 3 formals
(https://github.com/jquery/sizzle/commit/51ba62312
On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote:
> OK, let's up the topic. Seems there are no technical issues in the proposed
> thing -- we can simply either accept it or not. The question is whether it's
> needed and sound proposal and the feature to have in ECMAScript.
There certain
On Aug 31, 2011, at 1:57 AM, Dmitry A. Soshnikov wrote:
> On 30.08.2011 20:39, Allen Wirfs-Brock wrote:
>> On Aug 30, 2011, at 12:39 AM, Dmitry A. Soshnikov wrote:
>>
>>> OK, let's up the topic. Seems there are no technical issues in the proposed
>>> thin
On Sep 1, 2011, at 8:55 AM, Dean Landolt wrote:
>
>
> On Thu, Sep 1, 2011 at 11:38 AM, Rick Waldron wrote:
> Just want to clarify that neither jQuery nor its selector engine Sizzle have
> any occurrences of function arity checking via the function length property.
> Both codebases have occur
On Sep 2, 2011, at 3:29 PM, Irakli Gozalishvili wrote:
>
> https://github.com/Gozala/doc
>
I want to second Brendan on the coolness of this. It really is a JavaScript
derived solution rather than simply copying what somebody else did for some
other language.
I have a couple of thoughts t
On Sep 3, 2011, at 11:59 AM, Thomas L. Shinnick wrote:
> An issue popped up where V8 recently made everything in Error objects
> non-enumerable. This was surprising to some apps. More surprising is the
> insistence that this is required by the ES5 spec.
>
> As a simplistic reader, when "own
On Sep 7, 2011, at 11:27 AM, Dmitry Soshnikov wrote:
> On 07.09.2011 20:53, Brendan Eich wrote:
>> On Sep 7, 2011, at 9:29 AM, Dmitry Soshnikov wrote:
>>
>>> On 07.09.2011 19:33, Felipe Gasper wrote:
Why does Object.keys() not allow, as an option, iterating through
inherited propertie
On Sep 11, 2011, at 3:50 PM, Rick Waldron wrote:
> I was curious to learn what the fee, in USD, for 2012 Ordinary Membership of
> Ecma
The 2010 fee is listed at
http://www.ecma-international.org/memento/ordinary.htm I don't know whether it
has changed since then but I'm sure Istvan can tell y
There are key points in Breton's post below that should not be lost in a
debate on whether or not dynamic JS performance can or can not asymptotically
approach that of a hypothetical class-based statically typed language
(something that you might call simply "J").
Success with a dynamic langu
On Sep 14, 2011, at 9:42 PM, Kyle Simpson wrote:
> I too have been confused by the name "weakmap"...partially because the name
> is misleading, and partially because documentation on it is
> ambiguous/misleading. Specifically, "weakmap" really means "weakkeymap",
> because only the key is weak,
On Sep 15, 2011, at 6:49 AM, Andreas Rossberg wrote:
> On 15 September 2011 09:10, Brendan Eich wrote:
>> On Sep 14, 2011, at 11:09 PM, Allen Wirfs-Brock wrote:
>>
>>> I would prefer ObjectMap (the keys are restricted to objects).
>>
>> Now that you point i
On Sep 15, 2011, at 9:07 AM, Mark S. Miller wrote:
> On Thu, Sep 15, 2011 at 8:47 AM, Allen Wirfs-Brock
> wrote:
> [...]
> No the normal use case for WeakMaps is simply to make associations between
> objects and arbitrary values. The special GC behavior is necessary to avoid
On Sep 15, 2011, at 10:21 AM, Sean Eagan wrote:
> Would a WeakPair primitive be useful...
>
> let wp = new WeakPair(key, value);
> ...
> if(wp.hasKey(key)) {
> foo(wp.value());
> }
>
> WeakMap could be built on top of this primitive:
It's not that easy. Read
http://www.arnetminer.org/dev.do
On Sep 16, 2011, at 5:14 AM, Andreas Rossberg wrote:
> ...
> Consider writing a server. If I cannot rely on tail call optimization
> then writing its message loop as a recursive function (e.g. actors
> style) would be incorrect. If I cannot rely on GC, then allocating an
> object for each receive
On Sep 16, 2011, at 10:52 AM, Mark S. Miller wrote:
> On Fri, Sep 16, 2011 at 10:41 AM, Allen Wirfs-Brock
> wrote:
> [...]
> This is the exact situation that exists for any ECMAScript dynamic
> allocation. There are no guarantees in the ES spec. that resources alloc
On Sep 16, 2011, at 2:47 PM, Mark S. Miller wrote:
> On Fri, Sep 16, 2011 at 12:41 PM, Allen Wirfs-Brock
> wrote:
> [...]
> This all sounds reasonable but I don't see how it particularly impacts the
> actual specification.
>
> The spec has multiple customers. I a
I'd recommend sticking sticking with "ES.next" as much as possible. Everything
is still subject to change and there remains a lot of opportunity for creating
confusion by talking about what is "in" ES6.
Allen
On Sep 19, 2011, at 12:54 PM, Rick Waldron wrote:
> It appears that ES6 is ok: h
On Sep 19, 2011, at 3:05 PM, Brendan Eich wrote:
>
> You're right that the safer course is ES.next until we're further along. When
> is "further along" in your view?
>
One approach is to not describe a features as "being in ES6" until after it
first appears in an actual ES6 draft. From th
I have updated the wiki with my latest working draft of the ES.next ("ESA6")
spec.
Word and PDF versions are available.
They can be access from
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts
Please report issues using
https://bugs.ecmascript.org/enter_bug.cgi?product=Draf
let instance = Object.create(o);
instance.constructor(/* constructor args */)
This assumes that the new instance will inherit "constructor" from its
prototype chain (possibly all the way to Object.prototype.constructor (.i.e.
Object).
If you are careful to always code your constructors to return
On Sep 24, 2011, at 9:03 AM, David Bruant wrote:
> ...
> I'm a big fan of the proto operator proposal, however, as raised
> previously this operator relies on the object being created to have an
> intialisation syntax. This prevents, for instance, Date objects to have
> a custom prototype with th
perhaps the algol/pascal/PL/I /etc use of a "then" keywords wasn't such a bud
idea after all...
allen
On Sep 28, 2011, at 2:11 PM, Waldemar Horwat wrote:
> Thinking about the implications of paren-free, I see additional potential
> trouble spots in addition to the one I mentioned in the meeti
On Sep 28, 2011, at 7:40 PM, Oliver Hunt wrote:
> class Foo {
>var bar; // default value -> undefined
>var wibble = 5; // initialised fields desugar to statements at the head of
> the constructor
>const wiffle; // read barrier on uninitialised
But note that such read barriers must b
On Sep 29, 2011, at 6:04 AM, Dean Landolt wrote:
>
>
> On Thu, Sep 29, 2011 at 12:13 AM, Rick Waldron wrote:
>
>
> On Thu, Sep 29, 2011 at 12:09 AM, Rick Waldron wrote:
>
>
> On Wed, Sep 28, 2011 at 11:05 PM, Dean Landolt wrote:
>
> Holes can be detected and skipped by using the "in" op
On Sep 29, 2011, at 11:07 AM, Sean Eagan wrote:
> Sorry to drag on about array holes, but:
>
> Should holes in spread elements (e.g. [...holeyArray]) and arguments
> (e.g. f(...holeyArray)) reflect as holes in the array they are spliced
> into to avoid information loss ? The current proposal [1
On Sep 29, 2011, at 10:10 AM, Brendan Eich wrote:
> On Sep 29, 2011, at 6:06 PM, Oliver Hunt wrote:
>
>> I'm not too concerned about the read barrier -- in terms of runtime cost i
>> a) don't believe it would be something that people actually use :D, b) even
>> if they did use it would be suff
On Sep 29, 2011, at 12:14 PM, Sean Eagan wrote:
> On Thu, Sep 29, 2011 at 1:31 PM, Allen Wirfs-Brock
> wrote:
>>
>> ...
>
>> I haven't written the spec. for spread in argument lists but clearly
>> interior holes need to be passed as undefined. Trail
On Sep 29, 2011, at 3:03 PM, Brendan Eich wrote:
> On Sep 29, 2011, at 10:07 PM, Sean Eagan wrote:
>
...
>>
>> So if #[] is added as shorthand for a sealed Array, do you agree that
>> #[0,,1] should be a syntax error ?
>
> I thought I just said so ("Sure, this carries over for all tuple propos
On Sep 29, 2011, at 3:10 PM, Brendan Eich wrote:
> On Sep 29, 2011, at 11:03 PM, Brendan Eich wrote:
>
>>> Probably shouldn't have <| for value types either then right ?
>>
>> That's right, they are not objects.
>
> Or hrm, now that you mention it Allen did spec these, and they get wrapped
>
On Sep 29, 2011, at 3:44 PM, Brendan Eich wrote:
>>
>
> AFAIK, "we have them" is false in ES5 -- implicitly created primitive
> wrappers do not escape, and engines do optimize them away.
Yup, you are MarkM are correct about that. The implicit ones don't escape if
you keep inside strict mode
On Sep 29, 2011, at 4:54 PM, Brendan Eich wrote:
> On Sep 30, 2011, at 12:22 AM, Erik Arvidsson wrote:
> ...
>
>> class Derived extends Base { // Object literal body
>> constructor(x) { // constructor
>>this._x = x; // no special form
>>// Disallow return expr?
or if somebody wants t
On Sep 29, 2011, at 5:10 PM, Erik Arvidsson wrote:
> On Thu, Sep 29, 2011 at 16:54, Brendan Eich wrote:
>> On Sep 30, 2011, at 12:22 AM, Erik Arvidsson wrote:
>> ...
>> A "static" keyword is at this point traditional, but we all hate it.
>> Are we being too pure?
>> /be
>
> I would also be fine
below
On Sep 30, 2011, at 2:49 PM, Axel Rauschmayer wrote:
>> From: Waldemar Horwat
>> ...
>
>
> 1. Super property references (mainly methods)
> 2. Super constructor references
> 3. Subclassing (mainly wiring the prototypes)
> 4. Defining a class as compactly as possible (with subclassing, it
On Sep 30, 2011, at 9:42 AM, Erik Arvidsson wrote:
> On Thu, Sep 29, 2011 at 12:53, Allen Wirfs-Brock
> wrote:
>> Also, note that I've currently spec'd ES6 so that 'arguments' can be used as
>> a rest parameter name. In other words
>>
On Sep 30, 2011, at 3:40 PM, Bob Nystrom wrote:
>
>
> On Fri, Sep 30, 2011 at 3:17 PM, Allen Wirfs-Brock
> wrote:
> I'd argue that my pattern also supports #5 as IDE's can recognize the
> pattern. An imperative class definition of all that most Smalltalk
>
On Oct 1, 2011, at 8:23 PM, Axel Rauschmayer wrote:
> ...
>
> What do you think about the following variation of Allen’s pattern?
>
>const ClassName = SuperClass <| function(/*constructor parameters */) {
>//constructor body
>super.constructor(/*arguments to super constructor
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 a deeply nested "patch" to an object, which is
> sort of interesting to th
On Sep 30, 2011, at 7:33 PM, Dean Landolt wrote:
>
>
> On Fri, Sep 30, 2011 at 10:13 PM, Axel Rauschmayer wrote:
> One language feature from JavaScript that I miss are enums. Would it make
> sense to have something similar for ECMAScript, e.g. via
> Lisp-style/Smalltalk-style symbols plus ty
On Oct 2, 2011, at 5:02 PM, Russell Leggett wrote:
> On Oct 2, 2011, at 6:19 PM, Allen Wirfs-Brock wrote:
>
>>>
>>
>> Is that the
>> SuperClass <| {
>> ...
>> }
>> part evaluates to the prototype object, not the const
t] = [...Array(100)];
>
> // extract into function form ->
>
> // rest should still have 98 holes, not 98 undefined's
> (function(a, b, ...rest){})(...Array(100));
>
> On Fri, Sep 30, 2011 at 8:41 AM, Sean Eagan wrote:
>> On Thu, Sep 29, 2011 at 2:53 PM, Allen
On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
> wrote:
>> But Function.prototype.apply doesn't preserve holes.
>
> Function.prototype.apply doesn't preserve holes for the the
> `arguments` object, but rest parameters aren't yet standardized, and
On Oct 3, 2011, at 4:19 AM, Axel Rauschmayer wrote:
>
> Addendum: With the definition of the new operator as below (for non-function
> operands, if the operand is a function, things stay the same), do you think a
> reference from Person.constructor.prototype to Person is still necessary?
>
>>
});
> return Object.freeze(e);
> }
>
> var color = Enum("red", "green", "blue");
> var c = color.green;
> switch(c) {
> case color.red:
> alert("red");
> break;
> case color.green:
> a
On Oct 3, 2011, at 10:17 AM, David Herman wrote:
> A couple reactions:
>
> - strings are already interned in current engines for symbol-like
> performance; there's no need to introduce symbols into the language
Is this really true? It was my original assumption based upon string
semantics. H
On Oct 3, 2011, at 12:42 PM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 11:31 AM, Allen Wirfs-Brock
> wrote:
>>
>> On Oct 3, 2011, at 6:49 AM, Sean Eagan wrote:
>>
>>> ...
>
>> In the evolution of the ES language, argument lists predates the exis
On Oct 3, 2011, at 1:00 PM, Sean Eagan wrote:
> On Mon, Oct 3, 2011 at 11:35 AM, Allen Wirfs-Brock
> wrote:
>>
>> On Oct 3, 2011, at 8:45 AM, Sean Eagan wrote:
>>
>>> On Mon, Oct 3, 2011 at 10:30 AM, Erik Arvidsson
>>> wrote:
>>>&g
On Oct 1, 2011, at 11:11 AM, François REMY wrote:
> My code was not a fix, it was intended to show that while your first case’
> behavior was explained in the spec (super had to be null), the one of my own
> case was not (ie: the interaction of ‘super’ with bind).
All well defined in the propo
On Oct 3, 2011, at 5:15 PM, Quildreen Motta wrote:
> On 03/10/11 20:44, Axel Rauschmayer wrote:
>> super being rare and moving methods being rarer, I think the tradeoff for
>> performance is OK, especially as there will be a method that allows you to
>> move methods. If performance wasn’t an is
On Oct 3, 2011, at 6:26 PM, Axel Rauschmayer wrote:
>> Channeling for MarkM, if you use regular objects for the enumeration element
>> values you probably will want to freeze them all so they can't be used as a
>> communications channel.
>
> Immutability makes sense. I don’t understand the "co
l Prototype..." thread that eliminates the mis-ordered
or left-out constructor clause problem.
> On Oct 2, 2011, at 12:52 PM, Allen Wirfs-Brock wrote:
>>
>
...
> But, what if we allow:
> propName.{ ...}
> to occur in a PropertyAssignment position of an obje
On Oct 3, 2011, at 9:18 PM, Russell Leggett wrote:
>
> On the other hand, I'd also hate to see ES4 part 2.
>
Having been there I can assure you that the current state of ES.next
development is nothing like ES4. The most import difference is that ES4
incorporated core concepts that were stil
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
On Oct 6, 2011, at 4:25 PM, Quildreen Motta wrote:
> On 06/10/11 19:56, John J Barton wrote:
>> Recent syntax discussions head in a completely different direction,
>> introducing a seemingly large number of new symbols resulting in code that
>> isn't readable by current JS, Java, or C devs. Ins
(I'm starting a little late on a long thread so sorry if I repeat things that
have already been said.
On Oct 7, 2011, at 1:50 AM, John-David Dalton wrote:
> On Fri, Oct 7, 2011 at 10:17 AM, Jake Verbaten wrote:
>> Object.extend is the only method I shim on every es5 project, so +1
>>
>> Howeve
On Oct 7, 2011, at 9:13 AM, Juan Ignacio Dopazo wrote:
>
> On Fri, Oct 7, 2011 at 12:34 PM, Axel Rauschmayer wrote:
> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
> Object.copyOwnTo(source, target) to the name “extend” (which, to me, suggests
> inheritance).
>
Just
On Oct 7, 2011, at 9:23 AM, Axel Rauschmayer wrote:
> ...
>>
>> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
>> Object.copyOwnTo(source, target) to the name “extend” (which, to me,
>> suggests inheritance).
>>
I isn't clear from the attribution who said the followin
On Oct 11, 2011, at 11:53 AM, Jake Verbaten wrote:
> is there any kind of proposal for syntax that is like :
>
> var proto = {
> method: function() { },
> constructor: function(someValue) {
> this.things = someValue
> }
> };
>
> var o = new proto(someValue);
> Object.getPrototype(o) ==
On Oct 11, 2011, at 1:46 PM, Jake Verbaten wrote:
> Yes the prototypes are still there. But that means im just using es3
> constructs. Es:harmony class literals only offer declarative sugar.
>
> I'm not proposing we change any of the existing Class.prototype.* code. I
> just propose that rathe
On Oct 11, 2011, at 4:03 PM, Kevin Reid wrote:
>>
>
> Well, in JavaScript you can always Object.create(Point.prototype, ...).
>
> In Java, for example, the ability to have multiple constructors can be very
> convenient for that type of use case; but it always can be replaced with
> factory m
The "ES6" specification has more complicated language constructs that require
more verbose specification language for many constructs. One of the techniques
I'm using is to have more semantic functions over grammar productions . The
readability of the specification seems to be quite sensitive t
On Oct 12, 2011, at 6:53 AM, Joe Developer wrote:
>
> I think an important question here is:
> Who are you actually trying to serve with your changes?
See the actual goals requirements and goals for ES Harmony at
http://wiki.ecmascript.org/doku.php?id=harmony:harmony
Requirements
New feature
On Oct 12, 2011, at 6:38 AM, David Bruant wrote:
> Hi,
>
> ...
> So I wondered "what if events were part of an object and exposed as such?".
> What if an object, instead of being "attributes+methods" was
> "attributes+methods+events"?
> (as I learned later having that thought, what I'm describ
On Oct 12, 2011, at 2:53 AM, Andreas Rossberg wrote:
>
> The third version seems far superior. It makes a proper, visible
> separation between static semantics and dynamic semantics, which is
> very helpful, and standard practice as well.
#3 was also my favorite from the first batch
>
> In fac
und 1985. I've yet
to see HTML document tooling that addresses the WYSIWYG production of
documents of this complexity. It they are out there I would like to hear about
them.
Allen
>
> Rick
>
> On Wed, Oct 12, 2011 at 2:53 AM, Andreas Rossberg wrote:
> On 12 October
On Oct 12, 2011, at 11:11 AM, Dean Landolt wrote:
>
>
> On Wed, Oct 12, 2011 at 1:34 PM, Claus Reinke wrote:
> ...
>
> Assuming, of course, that the exported XML is not completely
> unreadable!-)
>
> It will be, at least to humans :)
>
> But it doesn't need to be -- there'd still be a huge
On Oct 12, 2011, at 12:22 PM, Dean Landolt wrote:
> So does chrome. If you view-source on it it appears to be binary -- and just
> as I suspected, it's actually just a zip (very much like odf). So for the
> curious, just download, change the extension to .zip and poke around to see
> if it's o
Alex, Erik, and I had a twitter conversation that eventually ran into the
inevitable limit of effective communications using 140 character messages.
This seems like a better place to capture and discuss the issues...
The conversation started about the new DOM API that Dart is proposing and my
The page you want is
http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator
It suggests pronouncing it as "prototype of". However, in most conversations
I've been in we've called it triangle.
the proposed operator symbol is <| not |>
Allen
On Oct 12, 2011, at 5:37 PM, John J Barton wr
On Oct 13, 2011, at 5:15 AM, David Bruant wrote:
> Le 13/10/2011 02:03, Allen Wirfs-Brock a écrit :
> ...
> So far so good
>
>> console.log(s instanceof Array); //true
> i think that this should be false.
> Object.getPrototypeOf(s) is the value of Object.get
On Oct 13, 2011, at 6:27 AM, Alex Russell wrote:
> Hey Allen,
>
> On Thu, Oct 13, 2011 at 2:03 AM, Allen Wirfs-Brock
> wrote:
>>
>> Alex also mentioned that a "use strict" for the DOM is needed, but we didn't
>> follow up on that. I'd li
Here's a picture that may help:
http://wiki.ecmascript.org/lib/exe/fetch.php?id=harmony%3Aproto_operator&cache=cache&media=harmony:triangleupdate.pdf
On Oct 13, 2011, at 9:23 AM, John J Barton wrote:
>
>
> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
On Oct 13, 2011, at 8:58 AM, David Bruant wrote:
> Le 13/10/2011 17:32, Allen Wirfs-Brock a écrit :
>>
>>
>>
>> you'd also need to include a constructor property in the new object in order
>> to make s instanceof SubArray work properly.
> Why so? &
On Oct 13, 2011, at 9:23 AM, John J Barton wrote:
>
>
> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
> wrote:
> ..
>
> My understanding of <| is that it sets the [[prototype]] property and nothing
> else. Consequently, I think that the semantics of "
On Oct 13, 2011, at 9:42 AM, Jake Verbaten wrote:
> Could the problem of mutating the [[Prototype]] not be solved by returning a
> new object with the [[Prototype]] set as the LHS and having the same
> [[Class]] and own properties as the RHS. I would change the semantics
> slightly.
>
> The o
On Oct 12, 2011, at 5:58 PM, Michael Dyck wrote:
> Allen Wirfs-Brock wrote:
>> The doc version of the latest stable draft is always posted at
>> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts I can
>> also start to post a docx version if there are
On Oct 13, 2011, at 10:21 AM, Brendan Eich wrote:
> On Oct 13, 2011, at 12:46 PM, Douglas Crockford wrote:
>
>> On 11:59 AM, Brendan Eich wrote:
>>>
>>> CoffeeScript users have to know JS semantics, even if they don't think of
>>> it that way.
>>>
>>> Syntax was the point, though, and product
On Oct 13, 2011, at 11:07 AM, Jay Skeer wrote:
> On 10/13/2011 09:23 AM, John J Barton wrote:
>>
>>
>>
>> On Thu, Oct 13, 2011 at 8:32 AM, Allen Wirfs-Brock
>> wrote:
>> ..
>>
>> My understanding of <| is that it sets the [[prototype]
On Oct 13, 2011, at 8:36 AM, Brendan Eich wrote:
> On Oct 12, 2011, at 5:28 PM, Dean Landolt wrote:
>
>
>> But this reminds me -- has anyone proposed a method shorthand for generators?
>
> Yes, it's easy:
>
> var x = {
> *foo() { yield ... }
> }
>
> The * goes after 'function' and before t
On Oct 13, 2011, at 12:07 PM, Brendan Eich wrote:
> On Oct 13, 2011, at 3:00 PM, Allen Wirfs-Brock wrote:
>
>> On Oct 13, 2011, at 8:36 AM, Brendan Eich wrote:
>>
>>
>> This is something that I'm been meaning to bring up:
>>
>> var x = {
>
On Oct 13, 2011, at 1:32 PM, Erik Arvidsson wrote:
> On Wed, Oct 12, 2011 at 17:03, Allen Wirfs-Brock
> wrote:
>
>> Finally Alex said that he needs "extensible Array types" and said that "the
>> committee hasn't moved quickly on that" . A subseq
On Oct 13, 2011, at 1:05 PM, Russell Leggett wrote:
> [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 no
On Oct 13, 2011, at 3:55 PM, John J Barton wrote:
>
> Suppose for a moment we allowed objects on the RHS:
>var o3 = p <| o2;
> Would we imagine that o2 was mutated in any way? I don't think so. Maybe
> there are binary ops that mutate operands, but they don't come to mind. So
> the entire
On Oct 13, 2011, at 5:08 PM, John J Barton wrote:
>
>
> On Thu, Oct 13, 2011 at 4:26 PM, Allen Wirfs-Brock
> wrote:
>
>
> I still haven't found a really compelling use case for a non-literal <| RHS
> and a good definition for object cloning is still a nut
On Oct 14, 2011, at 12:38 AM, Jake Verbaten wrote:
> I agree having two types of examplers is sensible.
>
> For examples sake let fExemplar be an exemplar constructed with new
> and les oExemplar be the other one.
>
> Now, I'm worried about "magically" making
>
> fExemplar <| oExemplar
>
>
On Oct 14, 2011, at 11:24 AM, Jake Verbaten wrote:
> One thing that worries me about the fsubo example is that
> oExemplar.constructor.prototype does not exist. How is that circular relation
> ship between .constructor and .prototype magically fixed?
>
>
This is something I alluded to in my
On Oct 16, 2011, at 4:05 PM, Axel Rauschmayer wrote:
>> From: Allen Wirfs-Brock
>
>
> Not surprisingly, I like oExemplars. They almost look like class literals,
> too.
>
> I’m a bit skeptical about having two competing exemplars (more than one way
> of a
On Oct 16, 2011, at 12:51 PM, Axel Rauschmayer wrote:
>> From: Allen Wirfs-Brock
>> Subject: Re: new
>> Date: October 11, 2011 23:50:14 GMT+02:00
>> To: Jake Verbaten
>> Cc: es-discuss
>>
>> It's still on my radar. Most recently see
>&g
On Oct 17, 2011, at 9:20 AM, Brendan Eich wrote:
> Back to a Proxy defaultValue trap. It should be derived as you say. It
> imposes no overhead on base-level objects. It seems unproblematic, but I
> can't for the life of me recall why it was left out. Mark or Tom would know.
The only polymorph
ES objects and their properties have always had a dual nature. They can be
used as both (semi-) fixed-shape object abstraction where the properties are
the member names and they can be used as open ended data collections where
property names are used as key values for accessing data in the coll
On Oct 17, 2011, at 2:38 PM, Dean Landolt wrote:
>
>
> On Mon, Oct 17, 2011 at 4:30 PM, Allen Wirfs-Brock
> wrote:
> ES objects and their properties have always had a dual nature. They can be
> used as both (semi-) fixed-shape object abstraction where the properties are
On Jun 11, 2012, at 11:03 PM, Yusuke Suzuki wrote:
> This issue is derived from Esprima issue 81
> http://code.google.com/p/esprima/issues/detail?id=81
>
> Hello everyone,
>
> According to the ECMA262 5.1th, [[Call]] of host object may return Reference
> Type.
> So, all values using raw [[Call
On Jun 12, 2012, at 8:49 AM, Herby Vojčík wrote:
>
> ...
>
> BTW, isn't this possible with comprehensions in parameter list:
>
> db.run = function (query, ...[...params, cb]) { /* body */ }
>
> If yes, problem solved.
Current draft requires an identifier after ... in a rest position
Allen
_
We have had several previous discussions about such possibilities on this list.
Bottom line, is that destructuring (including formal parameters) could be moved
towards something that is more like generalized pattern matching. However, it
isn't clear that the additional specification, implementa
On Jun 12, 2012, at 3:26 PM, John Tamplin wrote:
> On Tue, Jun 12, 2012 at 3:09 PM, Brendan Eich wrote:
> And (to be clear) the semantics for
>
> LeftHandSideExpression ?= AssignmentExpression
>
> are roughly
>
> Let lref = evaluate A.
> Let lval = GetValue(lref).
> Let rref = evaluate B.
> L
On Jun 14, 2012, at 9:49 AM, Hemanth H.M wrote:
> The inspect module provides functions for introspecting on live objects and
> their source code.
As do many of the ES5 methods in Object.*. It's not clear what you mean by
source code in this context.
If you want to have discussion about an i
On Jun 14, 2012, at 10:10 AM, Brendan Eich wrote:
>
> On semantics: CoffeeScript's use of != null to equate null and undefined
> matches some users' habits, and helps to conceal the awkward fact of two
> bottom-types in JS (@jashkenas just averred that was the goal). But such
> concealment ca
On Jun 14, 2012, at 10:22 AM, Brendan Eich wrote:
> Hemanth H.M wrote:
>> var info = { name: "Hemanth", url: "http://h3manth.com/";, location :
>> "Earth", get : function() {} };
>> Object.keys(info)
>> ["name", "url", "location", "get"]
>>
>> Now, it's not clear about the 'type' of the keys; n
On Jun 14, 2012, at 10:52 AM, Brendan Eich wrote:
> ...
> Thanks. Any reason this wasn't included in ES5 that you recall?
>
Minimalism. Object.* wasn't intended to be a comprehensive reflection library,
just a set of essential primitives that could be used tin building such.
Allen
_
On Jun 14, 2012, at 11:01 AM, Brendan Eich wrote:
> ...
>
> We have a problem with || indeed. The question is whether the solution should
> equate null and undefined. CoffeeScript chose the conceal-the-difference path
> and it has users. The users who want null to be distinct from undefined ar
On Jun 14, 2012, at 3:10 PM, T.J. Crowder wrote:
> Making a point of making this a separate thread from the current ?? and ??=
> thread(s), which are thankfully looking close to consensus. So that's infix
> and assignment.
>
> Question: Should we consider unary as well?
>
> I ask because I we
601 - 700 of 3206 matches
Mail list logo
