Yes, thanks, my mistake on the unexported startCar function declaration. My
question is more about semantics, if the author of engine did not want to
export start, the grammar allows anyone importing the engine module to override
the original author's intent.
On Jul 10, 2011, at 8:11 PM,
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two traversals that's in many Schemes is
map-filter or filter-map:
a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i)) if (res
!== void 0)]
I rather arbitrarily chose to
On 11.07.2011 2:42, David Bruant wrote:
Le 10/07/2011 22:46, Dmitry A. Soshnikov a écrit :
Here I put some extensions for arrays standard library (separated
from this thread:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html
where Array.of and Array.from were considered).
Le 11/07/2011 14:29, Dmitry A. Soshnikov a écrit :
On 11.07.2011 2:42, David Bruant wrote:
Le 10/07/2011 22:46, Dmitry A. Soshnikov a écrit :
Here I put some extensions for arrays standard library (separated
from this thread:
https://mail.mozilla.org/pipermail/es-discuss/2011-July/015856.html
http://wiki.ecmascript.org/doku.php?id=harmony:let
Given the following code:
var a = [];
for (let i = 0; i 3; i++) {
a.push(function () { return i; });
}
print(a[0]()); // 0 or 3?
I would expect this “desugaring”:
var a = [];
(function() {
var i;
On 11.07.2011 16:49, David Bruant wrote:
Le 11/07/2011 14:29, Dmitry A. Soshnikov a écrit :
On 11.07.2011 2:42, David Bruant wrote:
Le 10/07/2011 22:46, Dmitry A. Soshnikov a écrit :
Here I put some extensions for arrays standard library (separated
from this thread:
On 9 July 2011 14:42, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote:
Unlike Names, strings and numbers are forgeable, so if they were
allowed as keys in WeakMaps, the associated value could never be
safely collected. Names, by contrast, have identity.
Of course you are right, and I shouldn't
My point is that the map spec is a deterministic algorithm because
side-effects would be noticeable otherwise. However, this prevent
implementations where function calls would be done in parallel for instance
(for better performances). In some cases (like the one I showed), the exact
No, a module determines its exports by itself, and no one can override that.
Notice that you missed *two* export declarations, car.startCar *and*
car.engine.start. If the engine module doesn't export start, then the outer car
module cannot access it.
Dave
On Jul 10, 2011, at 11:19 PM, Kam
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 all generic.
We're
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(); // [1,
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 isGenerator, right? There is no Generator constructor, no
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 non-writable,non-enumerable non-configurable data property on
Function.prototype.
We're talking about isGenerator,
On Jul 11, 2011, at 7:18 AM, Axel Rauschmayer wrote:
I remember that this has been previously discussed, but can't find the
thread. For me, the above desugaring is easier to understand than the lambda
coding.
Just recently:
On Mon, Jul 11, 2011 at 8:32 AM, David Herman dher...@mozilla.com wrote:
My point is that the map spec is a deterministic algorithm because
side-effects would be noticeable otherwise. However, this prevent
implementations where function calls would be done in parallel for instance
(for
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 non-writable,non-enumerable non-configurable data property on
On Jul 11, 2011, at 10:25 AM, Allen Wirfs-Brock wrote:
I don't think we or anybody else has really explored the extensibility
implications of generator functions so it isn't surprising that there have
been no requests.
We certainly have explored generators (extensibility is not a good in
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 that grand...
Even less grand ones such as the DOM's
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
have to be a property on Function to
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 that grand...
On 11.07.2011 20:01, Allen Wirfs-Brock wrote:
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
I agree with Brendan's replies, but just to add some more color:
On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll anguscr...@gmail.com 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
On 12.07.2011 0:18, Bob Nystrom wrote:
I agree with Brendan's replies, but just to add some more color:
On Sat, Jul 2, 2011 at 11:46 AM, Angus Croll anguscr...@gmail.com
mailto:anguscr...@gmail.com wrote:
The concept itself is very simple - a dynamic archetype to be
shared by all my
I am warming up to class literals: they should help IDEs and will make future
extensions easier (mixins etc.). Note that they are not mutually exclusive with
prototypes as classes.
On Jul 11, 2011, at 22:18 , Bob Nystrom wrote:
I agree with Brendan's replies, but just to add some more color:
Just recently:
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015615.html (thread
head)
and previously:
https://mail.mozilla.org/pipermail/es-discuss/2008-October/007826.html
Thanks!
Compare: With Java, you have to declare
final int finalI = i;
inside a for loop if you
On Jul 11, 2011, at 2:54 PM, Axel Rauschmayer wrote:
As per Jon’s criticism, I would expect every iteration to create a new
environment whose outer environment is always the same – the environment
where i is bound (right?). That is: i is stored outside the environments
that are created by
On Jul 11, 2011, at 12:46 PM, Allen Wirfs-Brock wrote:
I think there is a (usually unstated) desire to also test for ES.next
features that may also start to show up as extensions to ES5 level
implementations. For example, generators in Firefox. You can't depend upon
modules in such
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 the value being tested in order to make the determination.
I'm not so sure about this
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 preferred over Array.isArray
This doesn't make sense to me.
On Jul 11, 2011, at 4:18 PM, Brendan Eich wrote:
So I think we took the wrong door here. Function.isGenerator by analogy to
Array.isGenerator,
... by analogy to Array.isArray, of course.
/be
or an isGenerator export from @iter (equivalent semantically), is the best
way.
However,
I'm not so sure about this now. I was just reviewing with Dave how the design
evolved. We had Function.isGenerator, analogous to Array.isArray. For taskjs,
Dave had thought he had a use-case where the code has a function and wants to
know whether it's a generator. It turned out (IIUC) that
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 preferred
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 the value being tested in order to
On 7/11/11 at 15:09, lior...@gmail.com (liorean) wrote:
On 10 July 2011 22:23, David Herman dher...@mozilla.com wrote:
Another common and useful fusion of two traversals that's in many Schemes is
map-filter or
filter-map:
a.filterMap(f) ~~~ [res for [i,x] of items(a) let (res = f(x, i))
On Jul 11, 2011, at 5:29 PM, Allen Wirfs-Brock wrote:
I was almost sold on this argument, but I see a different issue. Global
predicate functions like this aren't extensible. Array.isArray and
Function.isGenerator work fine because they are testing deep implementation
level
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
category test uses an instance property
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.
Do we have any examples of those in the spec., or contemplated for
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.
Like most principles, I think these are reasonable to keep in mind but
not absolute. In particular, I see no sensible
On Jul 11, 2011, at 10:00 PM, Luke Hoban wrote:
So I was wrong about iterators being the general interoperable runtime
mechanism, but next/send/throw/close objects appear to be fully iterable and
consumable in generators. Is that right?
That's right, there is no nominal type test.
If
If so, it seems safe to consider generators as sugar for producing objects
whose visible behavior could have been built independently. And
interoperation appears to work cleanly in both directions using these
objects.
You're talking about interoperation in the old script calls new generator
40 matches
Mail list logo
