>
> It doesn't specify how to print objects, except for %s, which says that if
>> the argument is not
>> a string, convert it to string using .toString().
>>
>
> If the format specifier does not apply to the argument given, it should
> raise exceptions. Except string conversion, no other conversion
>
> C#, CoffeeScript, and other languages use -> to link a formal parameter
> list to a function body, which requires bottom-up parsing in general (with
> comma as operator, as JS, C++, and C have; plus Harmony's destructuring and
> default parameter value proposals).
>
I'm not a parsing expert, b
I've implemented an unrelated language that works this way, and it is really
nice, but I don't know if moving ES to that after the fact would work. But
maybe I'm misreading your proposal. Consider:
function show(a, b, c) { log(a + " | " + b + " | " + c); }
var arg = [1, 2, 3];
show(arg);
Cu
>
> OTOH, if ? as an identifier suffix, no space allowed, were added to
> Harmony, then we would have a migration tax in the form of an early error,
> which *might* be ok:
>
I'd find that a bit astonishing since other punctuators (like prefix "-" and
"+" and postfix ":") don't work that way. If "?
>
> However, given the reality of ASI, in practice there are two ways to
> terminate statements. Then the question becomes, what is more usable,
> optionally turning off ASI, or under prior opt-in to Harmony, improving ASI?
>
I would love to be able to ditch my ";" in JS. There are other languages
On Mon, Apr 18, 2011 at 7:46 PM, Mike Samuel wrote:
> If I understand semicolon elision, then
>
> myLabel:
> for (;;) {}
>
> would be interpreted as
>
> myLabel: ;
> for (;;) {}
>
I'm still learning to details of the ES grammar, but I didn't think there
were cases where a ";" is valid after a ":
>
> I think there are a large number of programmers who, because of those
> java style guidelines and the way ASI works, write javascript breaking
> before operators except for comma operators.
>
> http://www.google.com/codesearch?q=%5Cx20%5Cx20%5Cx20%5B%2B-%5D%5B
> ^%2B-%5D+lang%3Ajavascript
> sho
>
> var a = 1
>> + 2
>> // a = 1
>>
>> var a = (1
>> + 2)
>> // a = 3
>>
>
> Ok, so you are advocating that adding extra parens is less typing and less
> prone to error than adding semicolons?
>
Yes, adding extra parens where needed and omitting ";" is less typing. To
verify, I just we
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 `new` as exactly the method of a class --
> Array.new, Object.new, etc. T
What about making the operator go in the other direction, like so:
{a:1,b:2} |> MyObject.prototype
[0,1,2,3,4,5] |> appBehavior
Array.create=function(proto,props) {
return Object.defineProperties([ ] |> proto, props)
};
let f = function () {} |> EnhancedFunctionPrototype
var p = /[a-m][3-7]/
On Wed, May 18, 2011 at 11:48 AM, Brendan Eich wrote:
> The whole of class declaration is a mouthful. 'function' and 'prototype'
> are overlong too.
>
Agreed. One of the reasons I'm really excited about this proposal is that it
addresses those:
// old and busted
function SomeClass() {}; SomeCla
ce property";
> };
>
> var c = new Ctor();
>
> console.log(
> c.method() // "own property"
> );
>
> Thanks in advance :)
>
> Rick
>
>
>
> On Wed, May 18, 2011 at 3:10 PM, Bob Nystrom wrote:
>
>> On Wed, May 18, 2011 at 11:48
On Wed, May 18, 2011 at 5:51 PM, Mark S. Miller wrote:
> On Wed, May 18, 2011 at 5:17 PM, Bob Nystrom wrote:
>
>> I believe it would be something like:
>>
>> class Ctor {
>> public method() {
>> return "own property";
>> }
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
>
>
> This is pretty rare, in my experience.
>
I just did some spelunk
On Thu, May 19, 2011 at 8:46 AM, David Griffiths wrote:
> For all the talk about what's "usable" and "readable", I haven't seen much
> mention of empirical testing done with ordinary people... (My sincere
> apologies if there's some usability test lab for middlingly intelligent
> JavaScripters
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
> conditionally?
>
Heh, zero, actually. We're pretty scrupulous here. The 34 examples fell
r
On Thu, May 19, 2011 at 11:47 AM, Brendan Eich wrote:
> Here's another question: how many property initializations could be done
> straight from the parameter of the same name?
>
Of the 88 fields I looked at, 10 were straight copies of a constructor
argument. Another 4 are copies with an "if und
On Thu, May 19, 2011 at 3:08 PM, Brendan Eich wrote:
> class Point {
> x = 0;
> ...
> }
>
> is a bit of a mystery.
>
> Is it an assignment expression-statement? No, no statements as *
> ClassElements*.
>
> Could it be creating a prototype property, as other unprefixed property
> initialisers
On Thu, May 19, 2011 at 5:20 PM, Brendan Eich wrote:
> Taken together, I wonder whether we aren't abusing *Declaration* to bind
> properties.
>
+1. I've been mostly working at this informally and haven't spent much time
looking at the EBNF yet, but I'd expect a class body to have its own set of
On Thu, May 19, 2011 at 5:40 PM, Brendan Eich wrote:
> Of the 88 fields I looked at, 10 were straight copies of a constructor
> argument. Another 4 are copies with an "if undefined then use this default
> instead" check.
>
>
> ??=, check (http://wiki.ecmascript.org/doku.php?id=strawman:default_op
On Thu, May 19, 2011 at 6:13 PM, Brendan Eich wrote:
> On May 19, 2011, at 6:08 PM, Bob Nystrom wrote:
>
> And there may be call sites like new SomeClass(undefined, "blah") I think
> most people try to minimize those cases, but they seem to crop up,
> especially as cod
On Sat, May 21, 2011 at 1:24 PM, Brendan Eich wrote:
> > It turns out now that it's really a dilemma what to choose -- arrows or
> blocks... have to think.
>
> Arrow function syntax is "just syntax". I will drop it if we can agree on
> block lambda revival. As @_sjs (Sami Samhuri) tweeted at me,
On Sat, May 21, 2011 at 6:39 PM, Brendan Eich wrote:
> Really, we're between these choices:
>
> 1. Do nothing, function + return 4ever.
>
> 2. Shorter function syntax by some abbreviation for 'function' that still
> requires 'return ' followed by an expression to return a value.
>
> 3. Block-lamb
>
> 1. More syntax means larger language surface, which adds complexity
> more things to remember / learn. More things to consider in ES.next.next
>
Yup, languages almost always tend to get bigger over time since it's really
hard to remove features.
For me, the goal isn't to make the language as
On Mon, May 23, 2011 at 8:51 AM, Brendan Eich wrote:
> Class syntax is like a lint brush for such features. If we add it, it will
> accrete more semantics (with unambiguous syntax, I hope) over time. This is
> just inevitable, in my view. It makes me want to resist classes and look at
> smaller a
On Mon, May 23, 2011 at 10:41 AM, Brendan Eich wrote:
> On May 23, 2011, at 10:03 AM, Alex Russell wrote:
>
> >> (A) the boilerplate needed to set up a sub-prototype object with correct
> constructor property, and
> >>
> >> (B) the pain of doing correct super calls by hand.
> >
> > I hope we can
>
> Using "public" to refer to an instance property seems totally weird to me.
>
For what it's worth, I agree. I'd prefer var or instance. I've already seen
at least one example of someone misinterpreting it and doing something like:
class C {
public someMethod() { ... }
}
Their intent was to
On Thu, Jun 2, 2011 at 10:15 PM, Kyle Simpson wrote:
> With all due respect, it's a somewhat common occurrence on this list when
> someone brings up an idea that bears even a remote resemblance to an
> existing official strawman, the instinctual and rapid triage is to shoehorn
> the discussion in
On Sun, Jun 5, 2011 at 9:35 PM, Peter Michaux wrote:
> Based on my understanding of what the desugared code would be, the
> last line above would be an error because Dragon.allMonsters is
> undefined.
That's correct. Do you have any examples of code where inheriting the
constructor objects would
It was. The main problem that comes to mind is that it doesn't work with
anonymous classes. Even with named classes, I find it can be tedious and
repetitive, especially with long class names.
Javascript's current class-as-constructor syntax is nicely terse and doesn't
require stuttering the "class
On Tue, Jun 7, 2011 at 1:19 PM, Gavin Barraclough wrote:
> Ah, good point, I hadn't considered anonymous classes. Clearly we could
> solve this with a solution specific to these cases (say, "class(){ /*...*/
> }" for anonymous class constructors?), but having mismatching syntax in
> these cases w
Either I'm out-of-date or the wiki page is. My understanding is that at the
TC39 meetings we decided to move instance and private record declarations
out of the class body and into the constructor. If that's the case, this
should be less confusing. You can no longer use "public" or "private" at the
On Wed, Jun 8, 2011 at 9:55 AM, Brendan Eich wrote:
> We can definitely leave protected out. My "seems inevitable" was in
> response to Kam bringing it up via a question that I expect will be
> frequently asked.
>
I really hope we can. My interest in adding class syntax to JS was that I
saw the
On Wed, Jun 8, 2011 at 11:50 AM, Allen Wirfs-Brock wrote:
> One of their main points is that the extensibility interface that a class
> exposes to subclasses should be treated as a distinct interface from the
> interface that the classes exposes to external clients.
>
This is an excellent insight
s.
> Is this one incorrect?
>
>
> On Jun 8, 2011, at 11:13 AM, Bob Nystrom wrote:
>
> Either I'm out-of-date or the wiki page is. My understanding is that at the
> TC39 meetings we decided to move instance and private record declarations
> out of the class body and into the c
On Wed, Jun 8, 2011 at 3:40 PM, Brendan Eich wrote:
> On Jun 8, 2011, at 11:13 AM, Bob Nystrom wrote:
>
> > Either I'm out-of-date or the wiki page is. My understanding is that at
> the TC39 meetings we decided to move instance and private record
> declarations out of the
On Sun, Jun 12, 2011 at 2:17 PM, Brendan Eich wrote:
> But to use the prototypal pattern, you would want something that has been
> discussed a bit: class elements (class body elements) defining
> once-per-class-evaluation function, let, and const bindings not as
> properties, but as lexical bindi
On Sun, Jun 12, 2011 at 2:38 PM, Brendan Eich wrote:
> Something about classes in JS makes me sad, an emotional effect I can't
> explain fully.
>
I'm one of the biggest fans of this class proposal, and I feel a twinge of
that sadness too. I look at it as JS taking a step away from Scheme and
t
On Tue, Jun 14, 2011 at 1:05 PM, felix wrote:
> How about using "prototype" or "proto" as the keyword instead of "class"?
>
> It's a declaration of a prototypical object used to generate other objects.
>
> "prototype" is already a familiar word to JS programmers; this is just
> extending its use
On Tue, Jun 14, 2011 at 1:34 PM, felix wrote:
> > I think that's been considered before. My complaint with it is that Point
> > isn't a prototype. It's a constructor function whose .prototype property
> is
> > the prototype. In other words, the object bound to the name Point isn't
> the
> > proto
On Tue, Jun 14, 2011 at 1:57 PM, felix wrote:
> On Tue, Jun 14, 2011 at 13:46, Bob Nystrom wrote:
> > On Tue, Jun 14, 2011 at 1:34 PM, felix wrote:
> >>> Hm, by that argument "class" isn't a particularly good term either,
> >> since the thing create
On Wed, Jun 15, 2011 at 4:31 PM, Mark S. Miller wrote:
> The shorthand {x, y} for {x: x, y: y} allowed on the left-hand side of
> assignment should be allowed on the right too ...
>
> This shorthand has nothing to do with quasis per se. It's just a convenient
> expression syntax. So if we allow
I like the simplicity of this, but I'm not crazy about how it merges two
distinct objects into one. TodayJS (and most class-based languages) let you
distinguish two things:
1. A set of properties relevant to the class itself.
2. A set of properties shared by each instance of the class.
In a class
On Tue, Jun 28, 2011 at 3:56 PM, Allen Wirfs-Brock
wrote:
(actually in the today's most widely used class-based languages (Java, C#,
C++) a "class" is no an object at all and don't have
properties/fields/polymorphic methods/etc. they really are just a scoping
mechanism. What you are saying is mo
On Tue, Jun 28, 2011 at 5:19 PM, Axel Rauschmayer wrote:
As an aside:
- Static methods in Java always felt like a hack, because Java’s creators
couldn’t bring themselves to support first-class functions.
- Thus: I would much prefer to put Object.* methods into a module (once we
have those). The sa
On Tue, Jun 28, 2011 at 6:38 PM, Brendan Eich wrote:
> It's true, classes want to slide down various lower slopes, over time. The
> "lint brush" problem, I called it. We on TC39 are obligated to hold the
> line.
>
Have you seen this occur in practice? My impression from C++ and C# is that
most o
I agree with Brendan's replies, but just to add some more color:
On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll wrote:
> The concept itself is very simple - a dynamic archetype to be shared by all
> my instances: my prototype changes, my instances know about it. I would not
> want to hide such a s
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 inheritance.
This is an important point. I think the reason most OOP languages make a
distinction b
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
>
> Arguably it doesn't. Java/C# static methods are not
> inher
On Mon, Jul 18, 2011 at 4:59 PM, Brendan Eich wrote:
> The primary purpose of a class is to define the behavior (methods) of
>> instances. It is describing an abstraction over all the possible instances.
>> The behavior of the singleton class object is typically secondary to the
>> primary abstr
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 subclass object you might look at the issue quite differently
>
> class Po
On Mon, Jul 18, 2011 at 9:09 PM, Brendan Eich wrote:
> On Jul 18, 2011, at 9:02 PM, Rick Waldron wrote:
>
> Hey Bob, FWIW...
>
>
>> class Point {
>> constructor(x, y) {
>> this.x = x;
>> this.y = y;
>> }
>>
>> zero() {
>> return new Point(0, 0);
>> }
>>
>> unit() {
>> re
On Tue, Jul 19, 2011 at 11:16 AM, Brendan Eich wrote:
> On Jul 19, 2011, at 11:07 AM, Bob Nystrom wrote:
>
> (It may be that we should use constructor: or static: instead of class:.)
>
>
> Those hurt more. I like class, it is shortest and closest to the keyword
> that intro
On Tue, 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 ru
On Tue, Jul 19, 2011 at 3:45 PM, Brendan Eich wrote:
> On Jul 19, 2011, at 3:13 PM, Allen Wirfs-Brock wrote:
>
> The plain name; also looks like a useless expression-statement.
>
>
> When we talked some people pretty strongly felt that it was very desirable
> to be able to explicitly declare the
>
> Particular, if a programmer sets up an editor template that inserts:
If we're OK with relying on tooling to type the boilerplate for us, I'm not
sure there's much reason to add any new sugar at all. At that point, we
could just set up the tools to insert:
function classname() {
subclas
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 pattern. I personally didn't find it awkward, error-prone, or to
> present any reada
On Mon, Aug 8, 2011 at 3:14 PM, Allen Wirfs-Brock wrote:
> function First() {}
> function Second() {ihis.getCompetitor = function() {/*whatever*/*}}
> ...
> First.partner = (new Second).getPartner();//but getPartner is not
> defined yet
> First. competitor = (new Second).getCompetitor(); //bu
On Tue, Sep 27, 2011 at 10:30 PM, Brendan Eich wrote:
> On Sep 27, 2011, at 4:06 PM, Waldemar Horwat wrote:
>
> > Trying to understand Oliver's objections to the current class proposal.
>
> Oliver objects, as do others, to "punning" (my word) declarative syntax to
> define object properties, and
On Thu, Sep 29, 2011 at 4:22 PM, Erik Arvidsson wrote:
> However, it seems like all the issues we have seen are due to us
> trying to solve issues that already exist today with prototype based
> "classes". These involve (but are not limited to):
>
> 1. Don't let uninitialized objects escape
> 2. E
On Thu, Sep 29, 2011 at 6:20 PM, Brendan Eich wrote:
> On Sep 30, 2011, at 1:11 AM, Erik Arvidsson wrote:
>
> On Thu, Sep 29, 2011 at 17:08, Bob Nystrom wrote:
>
> class Monster {
>
> constructor(this.name, this.health) {}
>
>
> I <3 this. It beats the (publi
On Fri, Sep 30, 2011 at 10:56 AM, Brendan Eich wrote:
> On Sep 30, 2011, at 7:12 PM, Bob Nystrom wrote:
>
> We want a syntax for properties on the constructor, so is it worth it to
> specifically forbid that notation outside of the class: section?
>
>
> It's future-pro
On Fri, Sep 30, 2011 at 11:53 AM, Brendan Eich wrote:
> 1. Oliver and others *do* want x and y to be in scope somehow. They can't
> be via the |this| parameter object on the scope chain, though. That's
> dynamic scope (the prototype is extensible, or *a* prototype, possibly
> Object.prototype, is
On Fri, Sep 30, 2011 at 12:59 PM, Axel Rauschmayer wrote:
> I wholeheartedly agree with not obsessing about the token count. I’m very
> sensitive to context in this regard: in some contexts, I don’t mind or even
> welcome additional tokens, in other contexts I hate them.
>
> However, avoiding rep
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
> implementations every had and they generally had fine IDEs.
>
I'm not a Smalltalker, but I thou
On Fri, Sep 30, 2011 at 3:38 PM, David Herman wrote:
> I disagree. The super patterns are really painful and easy to get wrong in
> existing JS, and the benefits of combining a prototype declaration and
> constructor declaration in a single form shouldn't be dismissed. It's
> noticeably more read
On Fri, Sep 30, 2011 at 4:57 PM, Waldemar Horwat wrote:
> On 09/30/2011 04:37 PM, Brendan Eich wrote:
>
>> since we haven't come up with a way to do 2 and 5 that works,
>>
>
> That's what makes this into a dead end. Worse, by claiming the class
> syntax you'd be precluding finding a different wa
On Tue, Oct 4, 2011 at 10:52 AM, Mikeal Rogers wrote:
My main concern with *some* of the proposals is that I feel they add
> features and clever syntax for experts at the expense of keeping the
> language easy to understand for new programmers.
It's hard to satisfy both sets of users here. It's
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 function returns, it returns a s
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 recu
On Mon, Oct 10, 2011 at 1:33 PM, Dean Landolt wrote:
>
>
> On Wed, Oct 5, 2011 at 1:40 PM, Bob Nystrom wrote:
>
>>
>>
>> On Wed, Oct 5, 2011 at 7:18 AM, John J Barton <
>> johnjbar...@johnjbarton.com> wrote:
>>
>>>
>>>
>&
This fell off the list. Re-adding it as requested. :)
- bob
-- Forwarded message --
From: Bob Nystrom
Date: Wed, Oct 5, 2011 at 1:39 PM
Subject: Re: On "I got 99 problems and JavaScript syntax ain't one"
To: John J Barton
On Wed, Oct 5, 2011 at 11:06 AM, John
On Tue, Nov 22, 2011 at 10:41 AM, Brendan Eich wrote:
>
> Nothing there about arrays or regular expressions, and the function
> examples do *not* show anything like
>
> superFun <| function (...) {...}
>
> Instead of Ahem'ing, could you cite what you claim is a prior proposal
> with specifics sh
On Wed, Jan 11, 2012 at 10:10 AM, John J Barton wrote:
> The blog post http://yehudakatz.com/2012/01/10/javascript-needs-blocks/ makes
> the case for blocks that act like functions when passed as arguments but
> have loop-up rules more like nested blocks.
>
> Of course these are called 'block la
On Fri, Mar 16, 2012 at 10:48 AM, Brendan Eich wrote:
>
> Not hermeneutic spirals, just circles. Feels like the last year (we cut
> off ES6 proposals, modulo exceptions/tweaks, last May; we had a big-ish
> classes strawman synthesized from several prior proposals; we lost Bob
>
On Fri, Mar 16, 2012 at 4:22 PM, Brendan Eich wrote:
>
> And properties can be used before initialization in JS today (and in Dart
> -- you Google guys are not all following the same rules :-P).
>
This is definitely the strangest possible venue for discussing Dart, but...
That isn't entirely tr
On Mon, Mar 19, 2012 at 1:03 PM, Russell Leggett
wrote:
> The recent discussion “Using Object Literals as Classes” brought up some
> key points, but the general feeling I got and agree with is this: we need
> to get classes into ES6. As Kevin points out, even if it didn’t have all of
> the feature
I think this is really interesting.
This will look like I'm poking holes here, but please don't take that to
mean that I don't find the overall approach worth investigating. You can
consider anything I *don't *poke at to be a sign of approval. Some concerns:
*It looks like methods on the prototy
78 matches
Mail list logo
