On Tue, Oct 16, 2012 at 7:10 PM, David Herman wrote:
> On Oct 16, 2012, at 4:51 PM, John J Barton
> wrote:
...
>
> Concrete example: Even and Odd modules refer to each other, but the import
> statements occur after some initialization:
>
> module Odd {
> export let odd = function(x)
On Oct 16, 2012, at 4:51 PM, John J Barton wrote:
> On Tue, Oct 16, 2012 at 2:58 PM, David Herman wrote:
>> The weird thing about (a) is that code that appears to be straight-line
>> actually executes in somewhat more unpredictable (although deterministic)
>> order.
>
> I guess if we can hand
On Tue, Oct 16, 2012 at 2:58 PM, David Herman wrote:
> On Oct 15, 2012, at 6:45 AM, Kevin Smith wrote:
>
>> OK, so:
>>
>> module A {
>> console.log("a");
>> export var x;
>> }
>>
>> console.log("$");
>> import x from A;
>>
>> Does this print:
>
> Good question. The way
On Tue, Oct 16, 2012 at 4:06 PM, Yehuda Katz wrote:
> On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller wrote:
>> Getting the comments with a getter seems fine. Appending only the list of
>> comments with a setter is bad, as it does not resemble storage semantics.
>
> Do you mean appending only to
Yehuda Katz wrote:
I feel somewhat strongly that this is an appropriate use of a setter.
Using a method would give the API a static language feel for not
enough win. In the case of a well-defined API with well-understood
links between objects, a setter feels right to me.
I'm not super-religio
On Tue, Oct 16, 2012 at 6:26 PM, Mark S. Miller wrote:
> Getting the comments with a getter seems fine. Appending only the list of
> comments with a setter is bad, as it does not resemble storage semantics.
Do you mean appending only *to* to list of comments?
`comment.post = post` has similar
Yehuda Katz
(ph) 718.877.1325
On Tue, Oct 16, 2012 at 5:13 PM, Brendan Eich wrote:
> Yehuda Katz wrote:
>
>> Agreed. For example:
>>
>> class Post {
>>
>> }
>>
>> class Comment {
>>
>> }
>>
>> Post.hasMany("comments");
>> Comment.belongsTo("post");
>>
>> let post = new Post()
>> let comment = n
Yehuda Katz
(ph) 718.877.1325
On Tue, Oct 16, 2012 at 12:51 PM, Herby Vojčík wrote:
> This did not get to the list, reposting...
>
> Original Message
> From: Herby Vojčík
> Subject: Fail-fast on non-existing [[Get]]
> Date: Fri, 12 Oct 2012 22:42:05 +0200
> To: ECMAScript dis
On Tue, Oct 16, 2012 at 2:58 PM, David Herman wrote:
> prints "a" then "b" then "main". That's clearly a problem for simple
> concatenation. On the one hand, the point of eager execution was to make the
> execution model simple and consistent with corresponding IIFE code. On the
> other hand, e
Getting the comments with a getter seems fine. Appending only the list of
comments with a setter is bad, as it does not resemble storage semantics. I
would expect well written setters to at least be idempotent, and well
written getters to be side effect free.
On Tue, Oct 16, 2012 at 2:36 PM, Tab
On Oct 15, 2012, at 6:45 AM, Kevin Smith wrote:
> OK, so:
>
> module A {
> console.log("a");
> export var x;
> }
>
> console.log("$");
> import x from A;
>
> Does this print:
Good question. The way we have it currently specified isn't ideal for
concatenation, I th
Yehuda Katz
(ph) 718.877.1325
On Tue, Oct 16, 2012 at 5:43 PM, Allen Wirfs-Brock wrote:
>
> On Oct 16, 2012, at 2:36 PM, Tab Atkins Jr. wrote:
>
> > On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
> >>
> >> You might not agree with the above guideline, or choose to follow it.
> >> That's fine
On Tue, Oct 16, 2012 at 2:43 PM, Allen Wirfs-Brock
wrote:
> On Oct 16, 2012, at 2:36 PM, Tab Atkins Jr. wrote:
>> On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
>>>
>>> You might not agree with the above guideline, or choose to follow it.
>>> That's fine. But, what you you propose as an alter
On Oct 16, 2012, at 2:36 PM, Tab Atkins Jr. wrote:
> On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
>>
>> You might not agree with the above guideline, or choose to follow it.
>> That's fine. But, what you you propose as an alternative. What are your
>> guidelines for choosing to use an ac
On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
wrote:
> On Oct 16, 2012, at 1:25 PM, Yehuda Katz wrote:
>> Agreed. For example:
>>
>> class Post {
>>
>> }
>>
>> class Comment {
>>
>> }
>>
>> Post.hasMany("comments");
>> Comment.belongsTo("post");
>>
>> let post = new Post()
>> let comment = ne
On Oct 16, 2012, at 1:25 PM, Yehuda Katz wrote:
> Agreed. For example:
>
> class Post {
>
> }
>
> class Comment {
>
> }
>
> Post.hasMany("comments");
> Comment.belongsTo("post");
>
> let post = new Post()
> let comment = new Comment();
>
> comment.post = post;
> post.comments //=> [comment
Yehuda Katz wrote:
Agreed. For example:
class Post {
}
class Comment {
}
Post.hasMany("comments");
Comment.belongsTo("post");
let post = new Post()
let comment = new Comment();
comment.post = post;
post.comments //=> [comment]
I'm with Allen: you shoulda used a method!
I know, this is a
Erik Arvidsson wrote:
On Mon, Oct 15, 2012 at 12:23 PM, Brendan Eich wrote:
* get/set accessor may have effects on 'set' (see the DOM) but only on the
receiver object (and unobservably, any children that become garbage, e.g.
when trimming .length on an array-like).
That is very limiting, even
Agreed. For example:
class Post {
}
class Comment {
}
Post.hasMany("comments");
Comment.belongsTo("post");
let post = new Post()
let comment = new Comment();
comment.post = post;
post.comments //=> [comment]
This is similar to certain DOM APIs, and my expectation of a hypothetical
version o
Most recently I needed that to do polymorphic function dispatch on input
argument type. More specifics can be found here:
https://github.com/Gozala/method/blob/master/core.js#L121-127
This case may be quite exotic, but I remember running into this quite a lot,
can't use cases unfortunately. BT
On Mon, Oct 15, 2012 at 12:23 PM, Brendan Eich wrote:
> * get/set accessor may have effects on 'set' (see the DOM) but only on the
> receiver object (and unobservably, any children that become garbage, e.g.
> when trimming .length on an array-like).
That is very limiting, even as a guideline. Any
It would be helpful if that page listed licenses and minimum es
target versions (es5? es3?)
Yes, I was thinking of flagging at least commercial vs free tools at
some point (*). If I receive concrete information about target ES
versions for transpilers, I will add that, too (though that kind of
d
Yehuda Katz
(ph) 718.877.1325
On Tue, Oct 16, 2012 at 11:48 AM, Kevin Smith wrote:
>
>>> What do you think about the typo problem? Not a major issue?
>>
>
> It's javascript, so I guess I'm used to getting pinched every now and then
> by a little property misspelling. It's never caused me to mi
Brendan Eich wrote:
Agreed, this thread proposed an alternative that actually threw out
privacy in order to avoid collisions and match today's JS patterns.
I should have written "... threw out privacy in order to simplify and
focus only on avoiding collisions and matching "
/be
What you're saying is directly in line with what the i18n group was thinking:
Encoding conversion is still useful, but should probably be in a library of its
own, not in the general i18n library. I'm glad to see that this is happening.
--Rich Gillam
Lab126
On Oct 16, 2012, at 9:18 AM, Joshua
Allen Wirfs-Brock wrote:
On Oct 16, 2012, at 9:11 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
The module vs. let scope is also interesting. Allen said the literature favored
the latter but that wasn't clear from my nowhere-near-comprehensive reading.
Presumably that is a large part of o
On Oct 16, 2012, at 9:11 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>>> The module vs. let scope is also interesting. Allen said the literature
>>> favored the latter but that wasn't clear from my nowhere-near-comprehensive
>>> reading.
>>
>> Presumably that is a large part of our mot
Herby Vojčík wrote:
And if yes doesn't this mean it is better to use `public` instead of
`symbol` in standalone non-private symbol declarations, as well, for
the consistency?
Syntax is being debated. Allen used 'symbol' but 'public' is another
candidate (and already reserved).
/be
_
This did not get to the list, reposting...
Original Message
From: Herby Vojčík
Subject: Fail-fast on non-existing [[Get]]
Date: Fri, 12 Oct 2012 22:42:05 +0200
To: ECMAScript discussion
Hello!
I have just looked the video on channel9 between Lars Bak and Anders
Hejlsberg, an
Allen Wirfs-Brock wrote:
On Oct 15, 2012, at 6:02 PM, Brendan Eich wrote:
Axel Rauschmayer wrote:
One thing to consider: I would expect IDEs to help with this. For example,
Eclipse does a pretty good job of letting one forget that one has to import
things before one can use them.
Maybe, b
On Mon, Oct 15, 2012 at 5:51 PM, Gillam, Richard wrote:
> **
>
> *Encoding conversion and detection.* Most of the time, text has already
> been converted to UTF-16 before it surfaces in JavaScript, so the use cases
> here basically all revolve around reading legacy file formats and
> communicat
Allen Wirfs-Brock wrote:
The module vs. let scope is also interesting. Allen said the literature favored the latter but that wasn't clear from my nowhere-near-comprehensive reading.
Presumably that is a large part of our motivation for providing lexically scoped let/const/function/class rather
>
>
>> What do you think about the typo problem? Not a major issue?
>
It's javascript, so I guess I'm used to getting pinched every now and then
by a little property misspelling. It's never caused me to miss
C#/C++/Java/etc. And it all washes out with proper testing.
It seems orthogonal to me a
Yehuda Katz
(ph) 718.877.1325
On Tue, Oct 16, 2012 at 9:45 AM, Kevin Smith wrote:
> 1. The one-class-per-file pattern is near universal. When there is more
> than one class, they tend to be in minor supporting roles (like
> exception-type subclasses or simple data structures).
>
> 2. Adding pr
On Oct 15, 2012, at 9:20 PM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> ...
>
> So you're right, orphaned children suffer mutation to null .parentNode --
> legacy feature indeed!
>
>> but most alternatives would make it either directly or indirectly observable
>> via the captured elem
On Mon, Oct 15, 2012 at 7:44 PM, Norbert Lindenberg <
ecmascr...@norbertlindenberg.com> wrote:
> The 12 October 2012 draft of the ECMAScript Internationalization API
> Specification is available at
> http://wiki.ecmascript.org/doku.php?id=globalization:specification_drafts
> and due to popular dem
On Tue, Oct 16, 2012 at 9:21 AM, Kevin Smith wrote:
> Patrick, it must be the other way. Here's why:
>
> module A {
> export function f() { console.log("A"); }
> }
>
> A.f();
>
> No import required before usage of an inline module. There is a
> concatenation strategy which w
1. The one-class-per-file pattern is near universal. When there is more
than one class, they tend to be in minor supporting roles (like
exception-type subclasses or simple data structures).
2. Adding private, protected, etc. declarations to classes adds a good deal
of baggage to the syntax that m
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Yehuda Katz
Sent: Tuesday, October 16, 2012 09:13
> Or, more commonly, symbols that are used in a single class that happens to be
> inside a module. Although I can't be sure about this, I expect that a larg
Yehuda Katz
(ph) 718.877.1325
On Tue, Oct 16, 2012 at 9:21 AM, Kevin Smith wrote:
>
> Just to be sure... Does a get printed only the first time the module A is
>> imported somewhere, or every time?
>>
>
> Only the first time. But the question here is about nested/inline modules.
>
> Patrick, i
> Just to be sure... Does a get printed only the first time the module A is
> imported somewhere, or every time?
>
Only the first time. But the question here is about nested/inline modules.
Patrick, it must be the other way. Here's why:
module A {
export function f() { console.log(
Yehuda Katz
(ph) 718.877.1325
On Mon, Oct 15, 2012 at 9:46 PM, Allen Wirfs-Brock wrote:
>
> On Oct 15, 2012, at 6:02 PM, Brendan Eich wrote:
>
> > Axel Rauschmayer wrote:
> >> One thing to consider: I would expect IDEs to help with this. For
> example, Eclipse does a pretty good job of letting o
Just to be sure... Does a get printed only the first time the module A is
imported somewhere, or every time?
On Tue, Oct 16, 2012 at 3:57 PM, Patrick Mueller wrote:
> On Mon, Oct 15, 2012 at 9:45 AM, Kevin Smith wrote:
>
>> OK, so:
>>
>> module A { console.log("a"); export var x; }
>> c
On Mon, Oct 15, 2012 at 9:45 AM, Kevin Smith wrote:
> OK, so:
>
> module A { console.log("a"); export var x; }
> console.log("$");
> import x from A;
>
> Does this print:
> $
> a
> or
> a
> $
>
The first - "$", then "a".
At least, that's how most module systems I've
It would be helpful if that page listed licenses and minimum es target
versions (es5? es3?)
Regards
On Oct 16, 2012, at 5:12 AM, Claus Reinke wrote:
>
> With ES6 engine compatibility still looking somewhat red
>
> http://kangax.github.com/es5-compat-table/es6/
>
> transpilers are not just a use
45 matches
Mail list logo
