Re: Array.prototype.contains
...and same for indexOf and lastIndexOf? ;-) On 7 mar 2014, at 13:33, Domenic Denicola dome...@domenicdenicola.com wrote: If that's the argument, then Array.prototype.contains should accept another Array, not an element to check. On Mar 7, 2014, at 5:49, medikoo medikoo+mozilla@medikoo.com wrote: Domenic Denicola-2 wrote Personally I think the more useful model to follow than `String.prototype.contains` is `Set.prototype.has`. API wise, arrays have much more in common with strings than with sets. Thinking ES5, they're both array-likes, set isn't. They share `length` property, their values can be accessed through indexes arr[0], str[0], they share few method names (`indexOf`, `lastIndexOf`), and all non destructive array methods can be successfully executed on strings, while they won't work with sets. I think it would be more appropriate to stick with `arr.contains` especially that we already have `arr.indexOf` and `str.indexOf`, and both `indexOf` and `contains` share same signature. `arr.has` could be fine, if we also rename `str.contains` to `str.has`. -- View this message in context: http://mozilla.6506.n7.nabble.com/Array-prototype-contains-tp309926p310234.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add intersections and unions to Set
+1 Additionally I propose to give more JS friendly method names: Intersection as `and`: set1and2 = set1.and(set2); Union as `or`: set1or2 = set1.or(set2); Complement as `not`: set1butNot2 = set1.not(set2); Peter Michaux wrote: On Mon, Mar 4, 2013 at 10:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 4, 2013 at 10:08 AM, al...@instantbird.org wrote: It would be useful to be able to form the intersection and the union of two Sets. These are natural operations that are currently not part of the API (http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets). Similar methods would make sense for Map, but one would have to think about what to do in the case where the key but not the value matches. An intersection is equivalent to a particular filter, so an alternative might be to add a method like Array.filter to Sets instead. (I filed bug 847355 for this and was told this mailing list was the right place for this suggestion.) Yes please, and also minus (remove from set A all elements it shares with set B). All three of these are fairly vital for a lot of code using sets. I agree that these methods would be useful. They are common set operations and they do seem missing from the Set draft spec. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Add-intersections-and-unions-to-Set-tp35134737p35243086.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: Mutable Proto
+1!
It would be great if someone will explain in detail why
Object.setPrototypeOf is no go.
We definitely need mutable prototype, but having it via __proto__ really
breaks the language.
Any function that blindly extends object with provided hash is affected e.g.
extend(obj, { __proto__: Error.prototype }).
Additionally it means that we need to serialize any user input which
eventually may be used as key on a dictionary e.g. data[userDefinedName].
That's bad, and it's hard for me to believe we can't do it better.
François REMY-3 wrote:
I certainly agree, but it has been decided otherwhise by the TC39 members
and I doubt they’re willing to revert their decision.
De : Andrea Giammarchi
Envoyé : 18 mars 2013 17:08
À : Nathan Wall
Cc : es-discuss@mozilla.org
Objet : Re: Mutable Proto
I would like to see Object.setPrototypeOf(object, proto) too and a
disappeared __proto__ 'till now breaking too much.
It would be much easier to implement all shenanigans via
Object.defineProperty(Object.prototype, '__proto__', {whatever}); rather
than fix current non-standard __proto__ ...
+1
On Mon, Mar 18, 2013 at 9:04 AM, Nathan Wall nathan.w...@live.com wrote:
A previous thread [1] brought to my attention the fact that objects which
don't inherit from Object.prototype won't have mutable __proto__. This
was something I had missed and breaks some scripts I'm currently using
because I have objects which I don't want to inherit from Object.prototype
but for which I do want to have mutable proto.
Testing in Firefox Nightly I found this workaround:
var x = { }, y = { foo: 'bar' };
x.__proto__ = y;
console.log(1, x.foo);
// = 1 'bar'
x.__proto__ = null;
console.log(2, x.foo);
// = 2 undefined
x.__proto__ = y;
console.log(3, x.foo);
// = 3 undefined
var _setPrototype = Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set,
setPrototypeOf = Function.prototype.call.bind(_setPrototype);
setPrototypeOf(x, y);
console.log(4, x.foo);
// = 4 'bar'
Is this workaround a temporary bug in Firefox's current implementation? Or
will this be the spec'ed behavior for ES6? Can we use such a method to
mutate prototype on objects which don't inherit from Object.prototype?
[1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029176.html
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Mutable-Proto-tp35188550p35196276.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: A case for removing the seal/freeze/isSealed/isFrozen traps
I've worked a lot with ECMAScript5 features in last two years, and I must say
I never found a good use case for Object.freeze/seal/preventExtensions, it
actually raised more issues than it actually helped (those few times when I
decided to use it). Currently I think that's not JavaScript'y approach and
use cases mentioning untrusted parties sounds logical just in theory, in
practice when actually we never include untrusted modules in our code base
does not make much sense.
However, main point I want to raise is that several times I had a use case
for very close functionality, that with current API seem not possible:
I'd like to be able to *prevent accidental object extensions*. I want to
control all enumerable properties of the object, so they can only be set via
defineProperty, but any direct assignment of non existing prop e.g.
'x.notDefinedYet = value' will throw. Imagine some ORM implementation, that
via setters propagates changes to underlying persistent layer, at this time
we cannot prevent accidental property sets that may occur before property
was actually defined (therefore not caught by the setter)
I assume that proxies will make such functionality possible, but maybe some
Object.preventUndefinedExtensions will be even better.
Brendan Eich-3 wrote:
Andreas Rossberg wrote:
On 14 February 2013 19:16, David Bruantbruan...@gmail.com wrote:
Le 14/02/2013 18:11, Andreas Rossberg a écrit :
You're being vastly over-optimistic about the performance and the
amount of optimisation that can realistically be expected for proxies.
Proxies are inherently unstructured, higher-order, and effectful,
which defeats most sufficiently simple static analyses. A compiler has
to work much, much harder to get useful results. Don't expect anything
anytime soon.
var handler = {set: function(){throw new TypeError}}
var p = new Proxy({a: 32}, handler);
p.a;
It's possible *at runtime* to notice that the handler of p doesn't have
a
get trap, optimize p.[[Get]] as target.[[Get]] and guard this
optimization
on handler modifications. Obviously, do that only if the code is hot.
I feel it's not that much work than what JS engines do currently and the
useful result is effectively getting rid of the forwarding overhead.
Is this vastly over-optimistic?
Yes. Proxies hook into many different basic operations, and there are
many special cases you could potentially optimise for each of them,
many of which don't come for free. I very much doubt that any vendor
currently has serious plans to go down that rathole instead of
spending their energy elsewhere. Certainly not before it is clear how
(and how much) proxies will actually be used in practice.
You're right in general, and we have not optimized, e.g. inlining
scripted trap calls.
We did do something special for our new DOM bindings I wanted to pass
along, in case anyone is interested:
https://bugzilla.mozilla.org/show_bug.cgi?id=769911
Thanks to bz for the link. This is yet another inline cache
specialization for expandos on nodelists.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/A-case-for-removing-the-seal-freeze-isSealed-isFrozen-traps-tp35013883p35026595.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Changing [[Prototype]]
Brendan Eich-3 wrote: In a more serious vein, we are at cross purposes with reality. Mutable __proto__ just *is*. It is a de-facto standard. (...) Self had writable parent slots. One can disagree with the design decision, but it's not unique to JS or uniquely evil. I'm totally after legalizing __proto__ (I already had few valid use cases for that in important projects) but maybe we should deprecate `__proto__` (being a property is really problematic) and standardize `Object.setPrototypeOf`? It would make things much cleaner and safe. Mariusz Nowak - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Changing---Prototype---tp34830218p34838926.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promises
Kevin Smith-21 wrote:
The only hard part that isn't really addressed by currently library
implementations is error handling. I feel pretty strongly that rejections
(and by extension, errors thrown from `then` callbacks), should ALWAYS be
observable. In other words, if a rejection is not observable via error
listeners at the time when error listeners should be called, then an
unhandled error should be thrown by the runtime.
In my usage of promises I have never wanted anything other than this
behavior.
I think source of a problem is that we center usage of promises just around
'then' function, when 'then' is about two things:
1. Provides us with resolved value
2. Extends promise chain with another promise.
What's important, in many use cases we're not after point 2, we don't need
extended promise, and it's promise extension fact that, makes our errors
silent when we don't expect them to be.
It's difficult to naturally expose errors when the only way to add observers
is `then`. Technically to do it we need to always write error handler as
below:
promise.then(function () {
// process the value;
}).then(null, function (err) {
// Need to get out of promise chain with setImmediate (or nextTick if in
Node.js)
setImmediate(function (function () {
throw err; // Finally error will be thrown naturally;
});
});
This one of the reasons for which some developers preferred to stay away
from promises, and I totally I agree with them.
Q implementors spotted that issue, and provided `done` (initially named as
`end`) function. Which helps to work with that issue:
promise.then(function () {
// process the value
}).done(); // Sugar for above
Still in Q (as far I as know) we're not able to get to resolved value
without extending the promise chain and that's not great.
Final conclusion is that there needs to be a way to observe resolved value
on promise without extending the chain as `then` does.
And yes there is library that does that. In deferred implementation
(https://github.com/medikoo/deferred ) I've solved it by providing two other
functions that have same signature as 'then' but *don't extend* promise
chain:
promise.end(onFulfilled, onRejected); // returns undefined
If onRejected is not provided then failed promise will throw, additionally
any errors that may occur in provided callbacks are thrown natural way
(they're not caught by promise implementation)
promise.aside(onFulfilled, onRejected); // returns self promise
This actually works similar to functions found in jQuery's Deferred. It's
useful when we want to return same promise, but on a side, work with
resolved value. If onRejected is not provided nothing happens (as we return
promise for further processing), but any errors that occur in callbacks are
thrown natural way (they're not caught by promise implementation)
With such design your function of choice in first place should always be
'end', in that case there is no problem with silent errors. `then` should be
used *only* if you have a reason to extend the chain, and pass result
elsewhere.
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Promises-tp34648686p34655893.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promises
Domenic Denicola-2 wrote: If I understand correctly, promise.done(onFulfilled, onRejected) does what you want in Q and in WinJS. See http://msdn.microsoft.com/en-us/library/windows/apps/hh700337.aspx for a nice explanation from the WinJS folks. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss When I scanned you're API not so long ago, it was as I described above. It looks you've changed the behavior with one of the recent v0.8 rollouts and that's definitely a good decision :) - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Promises-tp34648686p34655959.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Function length
I find Function 'length' as very useful property (I use it in some low-level
functional stuff). I also think that defining functions so it reflects only
required arguments is very sane decision. In that light I would also expect
...rest to not be counted in Function length.
+1 for keeping it, the way it is.
Brendan Eich-2 wrote:
I would not mind removing Function 'length' but on the web you cannot
deprecate and any browser daring to remove will appear broken to users
not involved in the content or the engine, and users switch browsers.
Anyway, back to reality: foo.length is in ECMA-262 and we need to spec
how it works in the presence of a trailing rest parameter. Allen has
drafted something based on discussion here. It's a plausible design and
hard to criticize without both your use-case (in detail) and a better
alternative.
/be
Irakli Gozalishvili wrote:
I don't think any library should ever rely on f.length.
That's a wrong attitude, there always will be legitimate uses of any
feature, otherwise such features are just harmful IMO should be
deprecated / removed.
It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
In some cases weather function captures `rest` arguments via
`arguments` is irrelevant. Like in a case I've pointed out earlier.
Library provides arity based dispatch based on f.length, so if you
pass `function() { arguments…. }` it will never be called with more
than 0 arguments.
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Monday, 2012-06-11 at 05:33 , Andreas Rossberg wrote:
On 10 June 2012 03:52, Irakli Gozalishvili rfo...@gmail.com
mailto:rfo...@gmail.com wrote:
I just noticed strange behavior in spider monkey implementation of rest
arguments:
(function(a, b, ...rest) {}).length // = 2
I think ignoring `rest` in length is pretty counter intuitive. For
example I
have small utility function that
I use to dispatch depending on argument length.
var sum = dispatcher([
function() { return 0 },
function(x) { return x },
function(x, y) { return x + y },
function(x, y, z) { return Array.prototype.slice.call(arguments,
1).reduce(sum, x) }
])
I don't think any library should ever rely on f.length. It is not a
reliable source of information (f might use 'arguments' even when the
length is officially 0), and I don't honestly see it being useful for
anything but tertiary debugging purposes.
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Function-length-tp33987815p33995683.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Sugar for *.prototype and for calling methods as functions
Sorry if it already has been picked up (I searched and didn't found anything close that). In my last months of work with JavaScript what that I miss a lot in ES5 syntax is: 1. Syntax shortcut for '.prototype'. Instead of writing String.prototype.trim I'd love to be able to write for example String#trim (it's not proposal, just example how it may look). As most native ES methods are generic there are a lot of valid use cases for that e.g.: Array#foEach.call(listThatsNotArray, fn); 2. Syntax sugar for calling method as a function. In following examples I just place '@' at end of method that I'd like to be run as function. Array#forEach@(listThatsNotArray, fn)); or trimmedListOfStrings = listOfStrings.map(String#trim@); Last example is same as following in ES5: trimmedListOfStrings = listOfStrings.map(Function.prototype.call.bind(String.prototype.trim)); This two proposals will make methods easily accessible for some functional constructs, and I think might be revolutionary for those who favor such functional way of programming. Let me know what do you think about that. -- Mariusz Nowak https://github.com/medikoo http://twitter.com/medikoo - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Sugar-for-*.prototype-and-for-calling-methods-as-functions-tp33363174p33363174.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
Andrea Giammarchi-2 wrote:
You are underlying my points too .. I am dealing on daily basis with
highly
dependent little modules and the build procedure takes care of packing
everything together before deployment.
However, we are using a synchronous version of require, similar to the one
used in node.js but that does not scale the day we would like to go
asynchronous in order to lazy load on demand only needed code.
On our side we're using version of require that's exactly same as in Node.js
(we also use Node.js and some modules are used on both sides) and
asynchronous loading in our case would rather be on package level not module
level (Node.js thinking) but even not exactly that way. It's more about
packs of modules that are needed to run other functionality (that we prefer
to load on demand) and those modules may come from various packages. That's
the approach we currently feel is right. We're using modules-webmake [1] for
client-side builds, but it's still limited as it doesn't support yet
intelligent split so modules are not duplicated in two different packs,
however we plan to address that soon.
Andrea Giammarchi-2 wrote:
Specially on mobile HTML5 applications where the manifest file is
included,
the lazy loading is handled by the browser itself and the module will be
almost instantly available once required later on if this was present in
the manifest.
What is missing is simply a common way that scales across all requirements
and I am sure you are using similar approach we do, stripping out
requires,
used only to order file inclusion before minification, using synchronous
loading on demand during debug ... isn't it?
We don't strip out requires, we were thinking about that, as it would
produce bit shorter and cleaner code (thinking one file) but the more we
work with Node.js style modules the more we acknowledge it may be quite hard
to achieve (unless you stick to some strict simple rules) but still I don't
see it as big deal, footprint that is currently added by modules-webmake[1]
is only 55 lines of code, and so far we don't feel it affects performance of
our applications.
We debug with not minified version of generated file, output from webmake is
very clear, and modules that were concatenated are not changed and usually
not big so it's easy to get around.
Andrea Giammarchi-2 wrote:
This is OK as long as your requirements won't change and, talking about
google, they do lazy load on demand many parts of their namespace too in
different applications 'cause a core of 1Mb does not simply scale over 3G
connections ... if you don't need that functionality instantly then why
creating such big package?
var module = require(module);
is totally fine but
require(module, function (module) {
// is totally fine too
});
latter could be synchronous in node.js and asynchronous in the web, who
cares, as long as it scales for all scenarios ... don't you agree?
Personally I don't like the need of extra closure. I want to be able to
write my code directly in a file. It may be a picking, but it's like
introducing to each of your modules extra maintenance code which has nothing
to do with logic of that module, I tend to avoid that as much as possible.
Andrea Giammarchi-2 wrote:
About AMD, yuno is 1Kb minzipped and it resolve dependencies with
parallels
downloads so you might be interested in having a look.
I looked at that with interest right when you published it, but currently I
really like the way modules work in Node.js, I'm fine with modules-webmake,
and I think it's currently the closest you can get to what will be
introduced in future with Harmony, so I plan to stick to that.
[1] https://github.com/medikoo/modules-webmake
--
Mariusz Nowak
twitter: http://twitter.com/medikoo
github: https://github.com/medikoo
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153281.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
rauschma wrote: @Andrea, Mariusz: Are you aware of the RequireJS optimizer [1]? It can be used together with almond [2], an AMD loader with minimal footprint. [1] http://requirejs.org/docs/optimization.html [2] https://github.com/jrburke/almond @Axel I read about it before, when we talk about synchronous loading then Node.js style modules with help of modules-webmake[1] is simpler and more powerful. I feel it's obvious. [1] https://github.com/medikoo/modules-webmake -- Mariusz Nowak twitter: http://twitter.com/medikoo github: https://github.com/medikoo - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33153338.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
rauschma wrote: I think introducing new language constructs for modules is good, because they are so fundamental. +1 rauschma wrote: For incrementally migrating old code bases, it would make a lot of sense to allow ES.next modules to import AMDs and vice versa. -1 I'm not sure if I understood this correctly, but trying to support backwards what was never a standard is probably not good idea, and AMD didn't get that much momentum to make exception for that, for many it's still controversial. rauschma wrote: Furthermore, npm’s ability to install modules locally and to let local modules shadow global ones is a very smart way out of version hell. It would be nice to have something similar for ES.next modules, but it’ll be harder to do for browsers (as opposed to for Node.js and local file access) It belongs rather to packages concept not modules (at least in that way it originated from CommonJS). Currently I can't imagine any need for packages implementation in browsers. It's strictly just server-side and I assume it's fine to not have it standardized -- Mariusz Nowak twitter: http://twitter.com/medikoo github: https://github.com/medikoo - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33148342.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Harmony modules feedback
Mark S. Miller-2 wrote: On Mon, Jan 16, 2012 at 7:51 AM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: rauschma wrote: For incrementally migrating old code bases, it would make a lot of sense to allow ES.next modules to import AMDs and vice versa. -1 I'm not sure if I understood this correctly, but trying to support backwards what was never a standard is probably not good idea, and AMD didn't get that much momentum to make exception for that, for many it's still controversial. While I agree that ES.next modules do not need to worry about AMD if it does not establish itself as a widely used de facto standard, I think we would all be better off if (the core subset of) AMD did become a wild success and ES.next felt the need to figure out how to manage the transition. It's very subjective, for example I don't see any added value in AMD (also subjective). I work with complex JavaScript (on client-side) applications, and AMD is not for us. Let me explain: The point is that there are two ways of thinking of modules, first is fine grained, when you care about DRY then your modules are rather small, it means that with AMD you would need to load hundreds of such modules asynchronously it wouldn't work even in dev environment. You may say - ok but you may pack it with [your favorite AMD packer] - then I ask, what's the point of using AMD when I don't need to load my modules asynchronously ? Other way of thinking is bigger picture: it's about modules that are larger packs of small modules that are loaded on demand, and this is when AMD can be useful, however again I don't see a point of using AMD just for that, implementations of AMD that I looked at are heavy and over-bloated for such simple need. If you look at the most complex JS applications in a web Today (e.g. Google +, Facebook) most of them are built exactly that way, fine grained modules packed into larger packs that are loaded on demand. Facebook even has they're own CommonJS style modules packer. So @axel saying that AMD is already a browser standard and it's just Node.js users that don't like it, is overstatement. I don't see a need for AMD in ES5.next and I'll be happy to refactor my CommonJS style modules for Harmony implementations when it will become a reality. -- Mariusz Nowak twitter: http://twitter.com/medikoo github: https://github.com/medikoo - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Harmony-modules-feedback-tp33125975p33149500.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
Rick Waldron wrote: On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: I like it, it indeed looks very logical, however it's a bit controversial that we need to create temporary array object to get one that we want. Is the controversy editorial or fact, because the following methods are all specified to use a temporary, newly initialized Array internally: Array.prototype.concat Array.prototype.filter (...) Rick, you say that apart of output arrays this methods create some other temporary arrays internally ? I don't see anything like that in specification, where exactly is it stated ? This doesn't produce the same as Array.prototype.repeat.. // regular console.log( Array.generate( 3, [1,2,3] ) ); // sparse console.log( Array.generate( 3, [1,2,,3] ) ); [ [ 1, 2, 3 ], [ 1, 2, 3 ], [ 1, 2, 3 ] ] [ [ 1, 2, , 3 ], [ 1, 2, , 3 ], [ 1, 2, , 3 ] ] It is supposed to be used that way: Array.generate(4, 1, 2, 3) // - [1, 2, 3, 1]; Usage you suggested as with Array.prototype.repeat will imply need of creating temporary array object. -- Mariusz Nowak https://github.com/medikoo - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33070367.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
Rick Waldron wrote: On Tue, Jan 3, 2012 at 3:34 AM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: Rick Waldron wrote: On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: I like it, it indeed looks very logical, however it's a bit controversial that we need to create temporary array object to get one that we want. Is the controversy editorial or fact, because the following methods are all specified to use a temporary, newly initialized Array internally: Array.prototype.concat Array.prototype.filter (...) Rick, you say that apart of output arrays this methods create some other temporary arrays internally ? I don't see anything like that in specification, where exactly is it stated ? Array.prototype.concat - http://es5.github.com/#x15.4.4.4 #2 Array.prototype.filter - http://es5.github.com/#x15.4.4.20 #6 (...) Rick, those arrays become result of each method, they're not temporary. - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33072157.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
Rick Waldron wrote: On Tue, Jan 3, 2012 at 9:19 AM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: Rick Waldron wrote: On Tue, Jan 3, 2012 at 3:34 AM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: Rick Waldron wrote: On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: I like it, it indeed looks very logical, however it's a bit controversial that we need to create temporary array object to get one that we want. Is the controversy editorial or fact, because the following methods are all specified to use a temporary, newly initialized Array internally: Array.prototype.concat Array.prototype.filter (...) Rick, you say that apart of output arrays this methods create some other temporary arrays internally ? I don't see anything like that in specification, where exactly is it stated ? Array.prototype.concat - http://es5.github.com/#x15.4.4.4 #2 Array.prototype.filter - http://es5.github.com/#x15.4.4.20 #6 (...) Rick, those arrays become result of each method, they're not temporary. Sorry, I should've been clearer... I was responding to your statement that implied Axel's example code was somehow creating an unnecessary temporary array - have I missed something here? Rick, what I meant is that it implies creation of temporary array object. Let's say I want to have an array made of numbers 1,2,3 repeated three times. To get it I need to create temporary [1, 2, 3] array which I don't really need: result = [1, 2, 3].repeat(3); It'll be more clean if it will work directly on context array: var x = [1, 2, 3]; x.repeat(2); console.log(x); // [1, 2, 3, 1, 2, 3]; but that probably won't be expected behavior by most developers. Anyway as Greg pointed, it's hard to find a valid use case for any array repeating method, it conceptually may look as nice add-on, but I'm not sure if it would be that useful to have it in standard. -- Mariusz Nowak https://github.com/medikoo/ - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33072532.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Array.prototype.repeat
I like it, it indeed looks very logical, however it's a bit controversial
that we need to create temporary array object to get one that we want.
Function (not method) that returns generated array may make more sense,
currently I'm using something like that:
var slice = Array.prototype.slice;
Array.generate = function (length, fill) {
var arr, l;
length = length 0;
if (arguments.length 2) {
throw new TypeError(Cannot generarte an array without provided
fill.);
}
arr = slice.call(arguments, 1, 1 + length);
while ((l = arr.length) length) {
arr = arr.concat(arr.slice(0, length - l));
}
return arr;
};
( https://github.com/medikoo/es5-ext/blob/master/lib/Array/generate.js )
--
Mariusz Nowak
https://github.com/medikoo/
rauschma wrote:
Array.prototype.repeat seems like a logical dual to
String.prototype.repeat:
http://wiki.ecmascript.org/doku.php?id=harmony:string.prototype.repeat
Implementation:
Array.prototype.repeat = function (times) {
var result = [];
var len = this.length;
var resultLen = len * times;
for(var i = 0; i resultLen; i++) {
result.push(this[i % len]);
}
return result;
}
In use:
$ [1,2,3].repeat(3)
[ 1, 2, 3, 1, 2, 3, 1, 2, 3 ]
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Suggestion%3A-Array.prototype.repeat-tp33067649p33068241.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: es-discuss Digest, Vol 52, Issue 117
rauschma wrote:
var c1 = Object.create(C);
obj.one(); // 'A.foo'
That would be c1.one(), right?
Yes, sorry edited post twice.
rauschma wrote:
|here| === C and thus the search for super.one starts in B and finds
A.one.
B.two = function () {
this.three();
};
B.three = function () {
return 'B.three';
};
C.two = function () {
super.two();
};
C.three = function () {
return 'C.three';
};
var c2 = Object.create(C);
c2.two(); // C.three
|here| === C and thus super.two === B.two
B.two() uses the original and unchanged |this| which is still c2.
= this.three === C.three
SUMMARY: I agree with your findings.
From my perspective, this proposal looks perfect. I wouldn't look further :)
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Re%3A-es-discuss-Digest%2C-Vol-52%2C-Issue-117-tp31889060p31892405.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Making super work outside a literal?
Brendan Eich-3 wrote:
Quoting from
http://wiki.ecmascript.org/doku.php?id=harmony:object_initialiser_super :
When a function contains a reference to super, that function internally
captures an internal reference to the [[Prototype]] of the object created
by the enclosing object initialiser. If such a function is subsequently
extracted from the original object and installed as a property value in
some other object, the internal reference to the original [[Prototype]]
is not modified. Essentially, when a function references super it is
statically referencing a specific object that is identified when the
function is defined and not the [[Prototype]] of the object from which
the function was most recently retrieved.
This behavior is consistent with that of most other languages that
provide reflection function to extract methods containing super and then
independently invoke them.
It's most sane proposal I think. However few things are not obvious to me,
will following evaluate as I assume:
var A = {
one: function () {
return 'A.foo';
}
};
var B = Object.create(A);
var C = Object.create(B);
C.one = function () {
return super.one();
};
var c1 = Object.create(C);
obj.one(); // 'A.foo'
B.two = function () {
this.three();
};
B.three = function () {
return 'B.three';
};
C.two = function () {
super.two();
};
C.three = function () {
return 'C.three';
};
var c2 = Object.create(C);
c2.two(); // C.three
Thanks!
-
Mariusz Nowak
https://github.com/medikoo
--
View this message in context:
http://old.nabble.com/Making-%22super%22-work-outside-a-literal--tp31880450p31884964.html
Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at
Nabble.com.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block lambda proposal in light of compiling to JavaScript
Brendan Eich-3 wrote: I noted the reaction here and in talks I've given, citing the straw poll I took about arrow functions, lambdas, there-can-be-only-one. 8/6/unanimous (some abstained). IOW, TC39 wants at most one lambda-or-just-shorter-function syntax (lambda carries semantics). The committee was mixed on arrow functions with Waldemar concerned about grammatical issues I've tried to address in the strawman. Others were quite in favor of arrows. Block lambdas were more divisive, in part because of the syntax, but in larger part (IMHO) because of the novel TCP semantics. Some on the committee decried excessive bits of cleverness. Others said won't this confuse n00bs? (Meta-discussion #27 from http://www.slideshare.net/BrendanEich/txjs-talk). More than a few were quite in favor, though (Allen, Dave Herman, Mark Miller). So, a mixed reaction and no consensus for ES.next. I'm +1 for block level lambdas. I think we definitely need shorter function syntax, so why not take it with additional power and simplicity that lambdas will give us. At least this: http://wiki.ecmascript.org/doku.php?id=strawman:block_lambda_revival looks very appealing to me. - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/block-lambda-proposal-in-light-of-compiling-to-JavaScript-tp31876202p31885102.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
