1:54 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> "does not allow runtime modification of all instances at once" meant
> through inheritance, through the proto, and its methods ...
>
>
> On Tue, Mar 19, 2013 at 1:53 PM, Andrea Giammarchi <
> and
oh dear ... even the example did not explain ... how can that be ?
@Rick is not because of my alzheimer that I did **not** freeze the private
object. I want to manipulate that because that's my object and I want to
expose objects that inherits from it without giving anyone the possibility
to reach
x27;\n'));
// undefined
// undefined
// "puppet"
}, 10);
---
If freeze is not available in IE5 it does not actually really matter. The
point/concept is about having an hidden prototype.
br
On Tue, Mar 19, 2013 at 3:23 PM, Andrea Giammarchi <
andrea.giammar..
ost common thing
on earth: add slice to it
(function(){return
arguments.__proto__||Object.getPrototypeOf(arguments)}()).slice=[].slice;
// example
(function(){
alert(arguments.slice(1)); // 2, 3
}(1, 2, 3));
br
On Tue, Mar 19, 2013 at 4:29 PM, Juan Ignacio Dopazo
wrote:
> 2013/3/19 Andr
ot;NO" or "use something else this is not a
problem", thanks
On Tue, Mar 19, 2013 at 5:03 PM, Rick Waldron wrote:
>
>
> On Tuesday, March 19, 2013, Andrea Giammarchi wrote:
>
>> oh dear ... even the example did not explain ... how can that be ?
>>
>&g
x27;till the day that would be possible, usually stuff I propose
takes 2 years before it goes out, it won't be the first time even here.
Best Regards
On Tue, Mar 19, 2013 at 5:21 PM, Brandon Benvie wrote:
> On 3/19/2013 5:17 PM, Andrea Giammarchi wrote:
>
> but [[Class]] of arguments
inside my bloody own prototype! ==> my own closure/private scope
On Tue, Mar 19, 2013 at 5:24 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> but it perfectly represent what I'd like to achieve through JavaScript, a
> "class" or prototype that does
/017076.html
so maybe I am not always that crazy when I ask about things and propose
stuff ... just maybe.
Thanks for listening
On Tue, Mar 19, 2013 at 5:24 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> inside my bloody own prototype! ==> my own closure/private sc
I don't understand where is the problem ... any library that uses __proto__
can and should be updated with a shim waiting for next version of JS to
support it.
Object.setPrototypeOf = function (object, proto) {
object.__proto__ = proto;
return object;
};
That does not look bad at all to me, e
David Bruant wrote:
> Le 20/03/2013 19:04, Andrea Giammarchi a écrit :
>
> I don't understand where is the problem ... any library that uses
> __proto__ can and should be updated with a shim waiting for next version of
> JS to support it.
>
> Which library? What are the
rds
On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron wrote:
>
>
>
> On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I think zepto is using that to modify runtime NodeList results after
>> querySelectorAll but
#x27;s objects, unless
> Object.setPrototypeOf were removed -- but that would break insecure-side
> code that reasonably (per your wishes) uses Object.setPrototypeOf in lieu
> of __proto__.
>
> Now do you understand?
>
> /be
>
> Andrea Giammarchi wrote:
>
>> never c
On Wed, Mar 20, 2013 at 10:18 PM, Brendan Eich wrote:
> Your writing is unclear and overlong, and full of unjustified airs of
> grievance -- please work on it.
I'll do more than that, I publicly and officially apologies for my writing
plus I will step back from this ML for an undefined amount o
"a principle or rule established in a previous case":
http://en.wikipedia.org/wiki/Precedent
I should not be here and I will not answer, just my last attempt trying to
make a point.
Please consider the main developer behind node.js agrees this property
should never land in JS as it's a minefield
en already deprecated
thing that will stay as it is for long time due not so new, and not so old,
Android devices, Nokia, etc.
All the best
On Fri, Apr 12, 2013 at 2:54 AM, Alex Russell wrote:
> Hey Andrea,
>
> Response inline.
>
>
> On Fri, Apr 12, 2013 at 9:01 AM,
> Adding Object.setPrototypeOf does not help, because code won't migrate to it
> completely so we'll be stuck with two APIs.
As shown in the first post we'll be stuck with 4 APIs plus the 5th one
standardized.
The __proto__ that is not supported, the one that is wrongly inherited
in Object.create
decide
to drop __proto__ and without an alternative the server could miss a handy
opportunity, for whoever needs it, to promote inheritance in existent
objects.
On Fri, Apr 12, 2013 at 4:05 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> > Adding Object.setPrototypeO
he doesn't need to fork V8, he simply needs to
delete Object.prototype.__proto__;
at startup time so I am getting real
On Fri, Apr 12, 2013 at 6:21 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> if you consider Object.setPrototypeOf an API and __proto__ another one
&
!
On Fri, Apr 12, 2013 at 6:27 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> he doesn't need to fork V8, he simply needs to
> delete Object.prototype.__proto__;
>
> at startup time so I am getting real
>
>
> On Fri, Apr 12, 2013 at 6:21 PM, Brendan Eic
I wonder if all of this is expected:
(function(){
"use strict";
function caller() {
alert(caller.caller);
}
// error if invoked: caller();
// but showing up in properties
var properties = Object.getOwnPropertyNames(caller);
if (properties.indexOf('caller')) {
console.log(JSON
what I've written here:
https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js
is a better proposal for the potential `Object.mixin()` in current ES6
specs.
It seems that Mixins Are Awesome and this can take most advantages from
being a function and not only an object:
http
apologies
getOwnPropertyDescriptor(
source,
key
)
should have been
getOwnPropertyDescriptor(
enricher,
key
)
On Sun, Apr 14, 2013 at 1:58 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> what I've written here:
>
> https://github.com/WebReflecti
also, in case you are guessing the typo .. reacher because it could reach
more (older) engines, doing a joke with richer got it? .. too damn
fun, I know!
On Sun, Apr 14, 2013 at 2:04 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> apologies
> getOwnProper
generalizing means that for any generic object we should try/catch to avoid
that error ? talking about automated code ... the "whitelist" is everyday
bigger :)
Thanks for the answer
On Sun, Apr 14, 2013 at 8:07 AM, Rick Waldron wrote:
>
>
> On Sunday, April 14, 2013, Andr
Object.mixin should be able
to accept a function and invoke it with target as context with optional
arguments would be really a **great idea**, IMHO
Thanks
On Sun, Apr 14, 2013 at 2:45 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> also, in case you are guessing
right, I've simplified a lot and tested cross platform:
https://github.com/WebReflection/object-mixin#object-mixin
thoughts?
On Sun, Apr 14, 2013 at 10:07 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> OK, maybe just code was a non-sense ...
>
> So, the i
nd Thang
> Object.mixin(Thung.prototype, Thing);
> Object.mixin(Thung.prototype, Thang);
>
>
> On Sun, Apr 14, 2013 at 12:59 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> right, I've simplified a lot and tested cross platform:
>>
>>
n Sun, Apr 14, 2013 at 2:24 PM, Angus Croll wrote:
> yeah that's better - I was having a senior moment - most constructor
> functions will normally reside in the prototype of course
>
>
> On Sun, Apr 14, 2013 at 1:59 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wro
at least in Firefox is working like that:
var blackMagic = Object.getOwnPropertyDescriptor(
Object.prototype, '__proto__'
).set;
var NaO = Object.create(null);
var o = {};
blackMagic.call(NaO, o);
o.isPrototypeOf(NaO); // true
if this will work cross browser like this adopting a method rath
spatchEvent: "trigger"
> }); /* obj_02 does feature the custom api names [on], [off], [hasObserver]
> and [trigger] - the underlying methods are the same as of obj_01 */
>
> With meta programming approaches this advantage, one gets for free now,
> might get lost or
-mixin/test/
Best Regards
On Sun, Apr 14, 2013 at 10:23 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> not sure changing name is a thing to promote, it makes method name
> clashing easier but it can be achieved simply attaching properties to a
> specific object and
It's a nice effort but I agree with Nuno that fragmentation even on these
things already in production (despite the versioning) out there and already
working practically for the real-world isn't any good for the next future
of the JS community.
Also, JS has been kept general purpose enough, I woul
Tab Atkins Jr. wrote:
> On Mon, Apr 15, 2013 at 1:51 PM, Andrea Giammarchi
> wrote:
> > It's a nice effort but I agree with Nuno that fragmentation even on these
> > things already in production (despite the versioning) out there and
> already
> > working practi
of course, that is just my opinion.
I am looking forward to read others ... meanwhile, in texas JS, a talk
about node streams:
http://2013.texasjavascript.com/stream/
Regards
On Mon, Apr 15, 2013 at 2:12 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I've implement
well, if the purpose is different and you need to describe streams as
"observables" or "signals" then I would suggest to change naming convention
so nobody will ever be confused again.
On Mon, Apr 15, 2013 at 2:36 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I think a large part
On Mon, Apr 15, 2013 at 2:04 PM, Tab Atkins Jr. wrote:
> > Also, JS has been kept general purpose enough, I would not try to
> influence
> > the language too much after DOM and W3C APIs and I thought this was also
> > same idea of TC39.
>
> I don't understand this sentence. It *sounds* like you'r
how about .pull() then, to read, and .push() to write :D
On Mon, Apr 15, 2013 at 5:34 PM, Jake Verbaten wrote:
> So one thing that is confusing is that `next()` has an API that looks like
> the stream is a "pull stream". A "pull stream" means that you call next()
> and it will give you the next
why is that?
void forEach(mapCB);
if that's to make it consistent with Array#forEach you should accept the
context argument in both map and forEach too?
However, I don't get why this should not work:
str.forEach(callback).then(notify);
Said that, I think is quite good after some renaming, b
yep, I was wrapping there already ... ain't needed.
Looking forward to see some example and read others opinion.
all the best
On Tue, Apr 16, 2013 at 5:20 PM, Tab Atkins Jr. wrote:
> On Tue, Apr 16, 2013 at 5:12 PM, Andrea Giammarchi
> wrote:
> > why is that?
> >
&
+1 to everything, but I would drop the literal too instead of promoting two
ways to do things.
off topic: I also hope __proto__ will be spec'd with a descriptor that
exposes the setter as it is now in Firefox, and not only the getter, as
conceptual language nonsense/restriction.
On Sat, Apr 20,
not sure I understand those examples, but the moment a developer starts
yelding everything, is the moment all non-blovking asynchronous advantages
are gone 'cause you are waiting instead of keep doing the rest, isn't it?
On Sat, Apr 20, 2013 at 9:56 PM, Domenic Denicola <
dome...@domenicdenicola.
you can hot-swap the chain, something Object.create() cannot do so it is
much more powerful, unless things changed that much lately ...
On Sun, Apr 21, 2013 at 11:03 AM, David Herman wrote:
> On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock
> wrote:
>
> > Deleting Object.prototype.__proto__ will
Agreed, but if you threat __proto__ as a different descriptor you also add
extra complexity.
Why not making as any other Object.prototype property exposing getters and
setters since these are what they are?
You have to add a description of these two and everything else will be
consistent with all
V8 already poisons when getOwnPropertyDescriptor has a setter and this
setters is the __proto__ one:
https://code.google.com/p/v8/source/browse/trunk/src/v8natives.js#390
This means V8 always throws and does not preserve the same realm, if I
understand what that means:
document.body.appendChild(d
Allen that's correct/expected ... as __proto__ is "own" in the
Object.prototype only or am I missing something?
On Sun, Apr 21, 2013 at 12:21 PM, Allen Wirfs-Brock
wrote:
>
> On Apr 21, 2013, at 11:53 AM, Brendan Eich wrote:
>
> Allen Wirfs-Brock wrote:
>
> ...
>
>
> This is specified by ES5, al
for how much I love being ignored, I agree on Brendan, once deleted, which
is an explicit action that means "get this stuff out of my environment"
nothing else should be affected.
If people would like to create enumerable/configurable/writable properties
at runtime together with specific inheritan
then you'll have ambiguous operations
obj[key] = value;
will not always do the same since
obj[key]
will not always do the same neither.
If a program decides/needs/wants no magic then magic should disappear and
if not in the chain it should not be inherited.
I'd rather leave, if really necessa
venient
as you want.
Not true the other way round
On Sun, Apr 21, 2013 at 1:09 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> for how much I love being ignored,
>>
>
> Not rehashing != ignoring.
>
>
> I agree on Brendan, once deleted, which is an explic
love it ... reminds me those days when [] or {} were invoking Array and
Object in some env ...
Anyway, I believe Allen is trying to say that {__proto__:whatever} should
be spec'd as syntax, regardless what will be of the
Object.prototype.__proto__ property/descriptor so that you can get rid of
it
agreed for consistency too, once deleted, the magic should disappear 100%
reality will be that most devs won't delete it so I don't see concrete side
effects out there.
However, this is how I would spec it (or better, how I would drop the axe
accepting a compromise for this property)
Object.getO
his is basically what's in V8 now (assuming d && property ===
'__proto__' can be true only with Object.prototype)
well, I am sure you all got the point about the possibility of replicating
or being completely free from this property
On Sun, Apr 21, 2013 at 2:11 PM, And
Off Topic: it's really funny that it took 10 years to teach people how
inheritance works in JS and today there's some legacy that instead of
constructors uses their objects or just objects as prototype so that
{__proto__:whatever} is considered a used pattern.
If the most common case is {__proto__
that won't work?
"__proto__" in {"__proto__":{}}; // true
"__proto__" in {__proto__:{}}; // still true, since "__proto__" in
Object.prototype, unless deleted
am I wrong?
On Sun, Apr 21, 2013 at 3:27 PM, Mark S. Miller wrote:
> Warning: The following is a sickening idea. I would really hate to
yak?!
On Sun, Apr 21, 2013 at 3:33 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> that won't work?
>
> "__proto__" in {"__proto__":{}}; // true
> "__proto__" in {__proto__:{}}; // still true, since "__proto__" in
>
n Sun, Apr 21, 2013 at 3:35 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> uh wait ... you meant ... uh ... wait, sorry, OK :D
>
> so {__proto__:Array.prototype} is an instanceof Array
> {"__proto__":Array.prototype} is an object with a "__proto__&
On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock wrote:
> We are free to specify a semantics that will make sense, now and for the
> long term.
>
>
then, for the long term, if all I understood about this thing is that
stinks for everybody, you should really consider to give developers the
possib
standards committee, we need to be realistic about when we can
>> exercise normative power and when we can't. I'll even agree that, when
>> we're uncertain, we should err on the side of cleaning things up. Until IE
>> changed expectation, we were doing exactly that
if Object.getPrototypeOf() works there, how is that secret protected?
In any case, do you agree since you can configure
Object.prototype.__proto__ you could also poison it by your own instead of
proposing an unusable poisoned setter as it is now in V8?
I am talking about this possibility (already
euse in those very few little edge cases.
Is this any more clear? Thanks for your patience, it's clearly hard for me
to express myself in your own terms.
Regards
On Sun, Apr 21, 2013 at 9:59 PM, Mark S. Miller wrote:
> On Sun, Apr 21, 2013 at 9:56 PM, Andrea Giamm
oh dear ...
var protoSetter = Object.getOwnPropertyDescriptor(
Object.prototype, '__proto__'
).set; // < forgot the setter in previous example
On Sun, Apr 21, 2013 at 10:07 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> right now this is the
then what's the point to poison
Object.getOwnPropertyDescriptor(Object.prototype,
"__proto__").set if anyone can always use __proto__ to change the chain ?
I don't understand this poisoning ... I don't see any advantage, only
problems if some library would like to drop __proto__ and use in edge ca
discussion oriented to SES again, I hope this won't be spec'd blindly after
some SES requirement that might be very different from, let's say, node.js
requirements, where the concept of security is not about evaluating runtime
unknonw code ... right? :-)
I keep being amazed by how many problems is
test driven specs development ... I like that. Everything seems to be OK
except one test is missing which is the key for me, the (hopefully not)
poisoned setter
On Tue, Apr 23, 2013 at 10:34 AM, David Bruant wrote:
> Hi,
>
> Based on recent messages on es-discuss, I feel that both es-discuss an
On Tue, Apr 23, 2013 at 10:23 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> discussion oriented to SES again, I hope this won't be spec'd blindly
> after some SES requirement that might be very different from, let's say,
> node.js requirements, whe
then is more Ha, ha, ha. Lulz, I told you, lulz! this one?
'__proto__' in {__proto__:null,"__proto__":null}
On Tue, Apr 23, 2013 at 5:34 PM, Jeff Walden wrote:
> On 04/21/2013 03:27 PM, Mark S. Miller wrote:
> > Warning: The following is a sickening idea. I would really hate to see
> us do it
Do you believe acting passively will keep bringing any good to the language
specification?
A **precedent**, title of one of my posts about __proto__, is exactly what
you have here.
"Since every browser has it, no matter how bad or good it is, let's us put
that there too and it will be standard"
_ from
the past?
This is a concern of mine, and I'd like to hear a clear statement about
this, thanks.
On Tue, May 7, 2013 at 10:24 AM, Mark S. Miller wrote:
>
>
>
> On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>&
fine for non-extensible objects, you might desire to keep a dictionary a
dictionary though, allowing properties extensions avoiding hot-swap
inheritance
2 options in my mind:
1. Object.freezeInheritance(generic), setting a [[MutablePrototype]]
internal property to false (true by default)
2. a
I proposed a flag for a reusable setter they told me they have no interest
to fragment the language behind these kind of flags ...
To all: a new syntax is also more suitable for shims/polyfills, something
broken/partial implementation of __proto__.set descriptor cannot replace
so, as direction, **
in the Example 1 you simply loop over all keys in the chain, included the x
inherited from b.
The fact you shadow that is irrelevant, it was there in any case.
The fact you get 1 in the log is because you access the shadowed property
through a[i] so expected result.
You are doing a for/in, not a
meanwhile, if V8 devs would like to play with the "how knows if/where to
put it" proposal, I've landed a patch that polish __proto__ poison from V8
and add, with tests I could think of, Object.setPrototypeOf native:
https://code.google.com/p/v8/issues/attachmentText?id=2675&aid=2675000&name=set
it took 8 years to teach JS developers **not** to pollute Object.prototype,
I understand your concern and I understand with the possibility to drop
enumerability that could (and will) be proposed by someone.
At the same time it will be a stubborn move aim to fix some deprecated,
old, not maintaine
I would rather bury __proto__ sooner through a
--no-black-magic-in-object-prototype V8 flag but again, I proposed a flag
and V8 said they don't want to go for this direction ... **actually it was
you saying that**
https://code.google.com/p/v8/issues/detail?id=2645#c3
"We have no interest in fragm
for what it matters, redefine.js already does exactly that.
( https://github.com/WebReflection/redefine#classes )
var Foo = redefine.Class({
extend: Bar,
mixin: [F, object, F2.prototype, Class3]
});
and yes, it makes perfect sense, specially for mixins such EventEmitter and
similar
my 2 cent
I've tried to find something like ECMA constitution or "how things work
here" page in what I think is the official ECMA website:
http://www.ecma-international.org/
I could not find what I am looking for, which is an answer to this question:
Does TC39 make decisions based on majority or unanimity?
2013 at 3:21 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> I've tried to find something like ECMA constitution or "how things work
>> here" page in what I think is the official ECMA website:
>> http://www.ecma-international.**org/ <http://www.ec
This seems more than reasonable so, for what I understand, is majority as
long as there's no **concrete** harm/problem/worst damage doing "that way"
that could make someone really disappointed.
Aka: consensus
On Fri, May 17, 2013 at 3:55 PM, Allen Wirfs-Brock wrote:
> When it comes time for TC3
OK, in your words is much better than in mine, got it, and thanks again.
On Fri, May 17, 2013 at 5:16 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> This seems more than reasonable so, for what I understand, is majority
>>
>
> No.
>
> "Majority"
does `Proxy` trap `Object.getPrototypeOf` somehow ?
If yes, why do you think having two namespaces for the prototype operation
is better?
If not, why do you think that is not needed in case of getting the
prototype?
In any case, how `Object.setPrototypeOf` differs anyhow compared to how the
`__pro
I believe having a counterpart in the Object, following a natural
expectation where for a get you've got a set, is just fine but surely
Reflect should have its own "reflection power" a part.
I see Reflect more like an introspection tool able to understand things and
not necessarily mutate them ( y
envie wrote:
> On 5/20/2013 10:55 AM, Andrea Giammarchi wrote:
>
>> I believe having a counterpart in the Object, following a natural
>> expectation where for a get you've got a set, is just fine but surely
>> Reflect should have its own "reflection power" a par
s
in specs for JSON too (together with for/in loops and property behavior
with null objects and not null objects)
Thanks and Best Regards
On Mon, May 20, 2013 at 2:55 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> that's fine with what I am thinking/saying ... it&#x
On Tue, May 21, 2013 at 12:56 AM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> can I also suggest to analyze, if there's still any doubt left on a
>> method VS a property yet, this piece of code if not highlighted before?
>>
>
> I do not understand what
for always work I meant as long as the object is not sealed/frozen as
discussed a while ago
On Tue, May 21, 2013 at 9:43 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> On Tue, May 21, 2013 at 12:56 AM, Brendan Eich wrote:
>
>> Andrea Giammarchi wrote:
>>
&
On Tue, May 21, 2013 at 9:47 AM, Brandon Benvie wrote:
> On 5/21/2013 9:43 AM, Andrea Giammarchi wrote:
>
> On Tue, May 21, 2013 at 12:56 AM, Brendan Eich wrote:
>
>> Andrea Giammarchi wrote:
>>
>>> can I also suggest to analyze, if there's still any doubt left on a
is simply static collection, so immutable:
```
var all = document.querySelectorAll("*");
var length = all.length;
all[length] = 'whatever';
alert(all.length === length);
[].push.call(all, 'whatever');
alert(all.length === length);
```
you can put properties because is extensible but you won't cha
I believe Tab is asking for something like:
`var MyNodeList = new ArrayType(EntryType, length);`
where `EntryType` is his own type and the result is an array like
collection or map.
At least, for what I understood, looks like he's asking for JS CTypes,
something rumored a while ago but never hea
you wrote:
What do I need to do to get a Map like that?
I answered but I've mistaken your original question and apologized already.
regards
On Wed, May 22, 2013 at 11:10 AM, Tab Atkins Jr. wrote:
> On Wed, May 22, 2013 at 11:00 AM, Andrea Giammarchi
> wrote:
> > I beli
I think `[mixin1, mixin2, mixin3].reduce(Object.mixin, source);` is a win,
only thing I am not sure, is how this third argument could make into this
approach (if reusable, I didn't even know about this extra arg)
Any hint on the extra arg appreciated for polyfill purpose, thanks
On Wed, May 22,
mething that was never taken as a real
> thing to apply.
>
> Dmitry
>
>
> On Wed, May 22, 2013 at 6:13 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> I think `[mixin1, mixin2, mixin3].reduce(Object.mixin, source);` is a
>> win, only thin
TC39 won't lie => TC39 won't like
On Wed, May 22, 2013 at 6:22 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I never hold on on polyfills, I already use Object.mixin in redefine.js
> and other personal code ;-)
>
> I think the direction is that s
Sorry but
`class B extends Object.mixing(Mixin1, Mixin2, Mixin3...)`
does not make sense to me ... would you mind explaining that ?
I am curious about this "need to have more args there" since nowadays there
are many ways to simulate that and `String.fromCharCode`, as example,
demonstrated alrea
tion is again to have it for users out of the box and
> design good APIs for end-users not bothering them to do this job for us.
>
> Currently these exact two methods are not a hi-pri, I believe there are
> more important things to discuss, but still those two would be great to
>
+1
as soon as the syntax is slightly different from NPM/AMD makes sense to
have less ambiguity and a better definition.
export default looks good here too
On Mon, Jun 3, 2013 at 12:57 PM, Domenic Denicola <
dome...@domenicdenicola.com> wrote:
> I really dislike `export =`. It looks like it sho
if
```
function x() {}
export default x;
```
works thought, that ain't any different from returning function expression
where you cannot reuse that function if not inside the function itself.
It does not look like a big lost but more similar to expression logic we
are use to with JS ... or, is i
which means it breaks explicit 'use strict' directive so, in my opinion, is
a legit question or, at least, this should be mentioned in the MDN page ?
On Thu, Jun 6, 2013 at 12:52 PM, David Bruant wrote:
> Le 06/06/2013 12:49, David Bruant a écrit :
>
> Hi,
>>
>> Should the "use strict" directi
and for "it breaks" I meant "it feels broken" ... this is not a real issue
but MDN should mention it to avoid any sort of confusion. I'll edit that
page, cheers
On Thu, Jun 6, 2013 at 12:54 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> which me
feel fere to update/change/improve my quick note in that page, thanks.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
I guess just consistency with other Array#forEach/map/every,etc,etc methods
plus you don't need to create N bound functions or N arrow functions per
each Array#find call ... or not?
On Thu, Jun 6, 2013 at 1:20 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:
> What would be the use ca
the fact reduce/Right a part all methods accept a thisValue ... I am happy
with current method though, still not sure if thisValue will be commonly
needed or not.
On Thu, Jun 6, 2013 at 3:44 PM, Rick Waldron wrote:
>
>
>
> On Thu, Jun 6, 2013 at 4:43 PM, Andrea Giammarchi <
&
601 - 700 of 1636 matches
Mail list logo
