Re: Array.prototype.contains
...and same for indexOf and lastIndexOf? ;-) On 7 mar 2014, at 13:33, Domenic Denicola 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" 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. > wrote: >> On Mon, Mar 4, 2013 at 10:08 AM, 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 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 Bruant 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
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: 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: 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 >> <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
James Burke-5 wrote: > > On Mon, Jan 16, 2012 at 10:33 AM, Mariusz Nowak > wrote: >> 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. > > This is provably false. You normally do not need hundreds of modules > to build a site. > I wasn't theorizing, I was talking about real applications that are already produced. James Burke-5 wrote: > > *But more importantly*, harmony modules also seem to be designed to > allow a separate request for each module. So your dislike of that > attribute will not go away with harmony modules. Harmony modules may > not need the function wrapper around the code as AMD does, but the > network request behavior will be similar to AMD. > I think Harmony modules have more in common with CommonJS than with AMD, and transition from CommonJS will be easier than from AMD. See slides 86-89 from http://www.slideshare.net/medikoo/javascript-modules-done-right (it's presentation I've done once on local Warsaw meetup) Of course Harmony will allow you to load each module separately, but with default syntax I understand it will work synchronously, I'm not sure we will do that for large number of modules. For asynchronous loading you may use dynamic loader which I think would be great to load bigger module dependencies. -- 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-tp33125975p33153466.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
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
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: 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: 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
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 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
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: Making "super" work outside a literal?
Peter Michaux wrote:
>
> On Mon, Jun 20, 2011 at 3:23 PM, Axel Rauschmayer
> wrote:
>
>> What is the use case for sideways calls? Can you point me to an example?
>
> You want to allow the API (a.k.a. public methods) of an object to be
> overridden, but you don't want the functionality of any non-overidden
> API methods to change. In short, you want to avoid the template
> pattern. I gave a synthetic example in the sideways calls thread I
> started.
>
Peter,
I'm actually not sure about that. I would even say that allowing such
sideway calls within 'instance' methods would be bad hint. I wouldn't like
to approach following code, it doesn't allow to extend A the way I may need
to:
var A = function () {};
A.prototype = {
one: function () {
return A.prototype.two.call(this, args...);
},
two: function () {
...
}
};
If we definitely need to call A.prototype.two whether we extended A or not,
then we probably talk about 'static' method which should not be called on
instance and should be defined directly on A (or privately within closure),
then we may just call it A.two(args...). At least that's what my OOP
experience says.
I understand your example at
http://old.nabble.com/super%2C-self%2C-and-sideways---durable-vs.-template-p31830714.html
to me it's just programmer mistake that should throw error.
Maybe you're looking for some pattern that can be realized using 'static'
methods (?) but forcing or introducing such behavior somewhere close 'this'
or 'super' logic might not be what people expect. My experience is not that
vast, is there any language that provide sugar for such calls ?
-
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-tp31889060p31892412.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: 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
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
