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
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 slightly...@google.comwrote:
Hey Andrea,
Response inline.
On Fri, Apr 12, 2013 at 9:01 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
a principle or rule
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
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 bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
Adding Object.setPrototypeOf
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 bren...@mozilla.com 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 Eich bren...@mozilla.com wrote:
Andrea
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')) {
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:
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/WebReflection/object-mixin/blob
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
getOwnPropertyDescriptor(
source
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 waldron.r...@gmail.comwrote:
On Sunday, April 14, 2013, Andrea
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 the typo
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 idea behind is mark
, 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:
https://github.com/WebReflection/object-mixin#object-mixin
thoughts?
On Sun, Apr 14, 2013 at 10:07
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 wrote:
My previous version was doing that in a probably too smart way so I've
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
libraries, that tried to be smarter than what the languages
core already provides except the last one that just sticks to a module
library.
On Sun, Apr 14, 2013 at 11:48 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
somebody already raised the concern what if I want to mixin
-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 then pass
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
. jackalm...@gmail.comwrote:
On Mon, Apr 15, 2013 at 1:51 PM, Andrea Giammarchi
andrea.giammar...@gmail.com 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 practically for the real
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 implemented Alex Future
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 of
On Mon, Apr 15, 2013 at 2:04 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
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
how about .pull() then, to read, and .push() to write :D
On Mon, Apr 15, 2013 at 5:34 PM, Jake Verbaten rayn...@gmail.com 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
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,
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. jackalm...@gmail.comwrote:
On Tue, Apr 16, 2013 at 5:12 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote
+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
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 dher...@mozilla.com wrote:
On Apr 21, 2013, at 8:55 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
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:
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
al...@wirfs-brock.comwrote:
On Apr 21, 2013, at 11:53 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
...
This is specified
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
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
as you want.
Not true the other way round
On Sun, Apr 21, 2013 at 1:09 PM, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
for how much I love being ignored,
Not rehashing != ignoring.
I agree on Brendan, once deleted, which is an explicit action that means
get this stuff
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)
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, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
agreed
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
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 erig...@google.com wrote:
Warning: The following is a sickening idea. I would
: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
Object.prototype, unless deleted
am I wrong?
On Sun, Apr 21, 2013 at 3:27 PM, Mark S. Miller erig
overwritten ... 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
Object.prototype, unless deleted
am I wrong?
On Sun, Apr
On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
, 2013 at 6:47 PM, Andrea Giammarchi
andrea.giammar...@gmail.com
mailto:andrea.giammarchi@**gmail.comandrea.giammar...@gmail.com
wrote:
On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com** wrote:
We are free to specify
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 by avoiding __proto__.
Today, we no longer have that happy uncertainty.
On Sun, Apr 21, 2013 at 6:47 PM, Andrea Giammarchi
andrea.giammar
.
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 erig...@google.com wrote:
On Sun, Apr 21, 2013 at 9:56 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote
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 V8 situation:
https
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
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
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 bruan...@gmail.com wrote:
Hi,
Based on recent messages on es-discuss, I feel that
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, where the concept of security is not about evaluating
runtime
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 jwalden...@mit.edu wrote:
On 04/21/2013 03:27 PM, Mark S. Miller wrote:
Warning: The following is a sickening idea. I would really hate to
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
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 erig...@google.com wrote:
On Tue, May 7, 2013 at 10:15 AM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Do you believe acting passively
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.
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
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
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
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
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?
Eich bren...@mozilla.com 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.ecma-international.org/
I could not find what I am looking
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 al...@wirfs-brock.comwrote:
When it
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
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 (
...@mozilla.comwrote:
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 part.
I see Reflect more like an introspection tool
behavior
with null objects and not null objects)
Thanks and Best Regards
On Mon, May 20, 2013 at 2:55 PM, Brendan Eich bren...@mozilla.com wrote:
Andrea Giammarchi wrote:
that's fine with what I am thinking/saying ... it's used as reflection,
to intercept, or to trap, and not used to do
On Tue, May 21, 2013 at 12:56 AM, Brendan Eich bren...@mozilla.com 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 you mean here.
I mean
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 bren...@mozilla.comwrote:
Andrea Giammarchi wrote:
can I also
Giammarchi wrote:
On Tue, May 21, 2013 at 12:56 AM, Brendan Eich bren...@mozilla.comwrote:
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 you mean
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
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
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. jackalm...@gmail.comwrote:
On Wed, May 22, 2013 at 11:00 AM, Andrea Giammarchi
andrea.giammar
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,
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 thing I am not sure, is how this third argument could make into
this approach (if reusable, I didn't even know
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 second argument to N extra is an old
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
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
reconsider.
Dmitry
On Wed, May 22, 2013 at 8:35 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
Sorry but
`class B extends
+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
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
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 bruan...@gmail.com wrote:
Le 06/06/2013 12:49, David Bruant a écrit :
Hi,
Should the use
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 means it breaks explicit 'use strict
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 case
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 waldron.r...@gmail.com wrote:
On Thu, Jun 6, 2013 at 4:43 PM, Andrea Giammarchi
yep, I followed Jussi ... it's his fault :P
sorry I misunderstood too
On Fri, Jun 7, 2013 at 7:03 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Oops, my bad, sorry about that.
On Jun 7, 2013 3:37 AM, Axel Rauschmayer a...@rauschma.de wrote:
Note: the proposed new parameter is
it comes out from time to time devs would like to have `Object.values()` as
equivalent of `Object.keys()` except the returned array would contain
values.
Better than repeated
`Object.keys(obj).map(function(p){return this[k];}, obj);`
all over
but probably less useful than a more generic
would this 'polyfill' as expected or there's more about these helpers ?
```javascript
this['@dict'] = {
keys: Object.keys,
values: function(keys){
function map(key) {
return this[key];
}
return function values(obj) {
return keys(obj).map(map, obj);
};
yep, that's awesome ... too bad not a single engine exposed yet such easy
change ever for both V8 and/or SpiderMonkey since everything is already in
place, only the public method exposed to JS is missing (and for V8 I've
already porposed a patch to drop the poison pill but nothing happened ...)
I
I believe Iterator should be an interface and not a class so I could extend
Array or ArrayLike implementing Iterator, when/if necessary, in order to
have a for/of compatible class.
We don't have interfaces ... I know, we could have mixins though,
compatible with @@things too.
My 2 cents
On
-brock.comwrote:
On Jun 11, 2013, at 10:22 AM, Andrea Giammarchi wrote:
I believe Iterator should be an interface and not a class so I could
extend Array or ArrayLike implementing Iterator, when/if necessary, in
order to have a for/of compatible class.
We don't have interfaces ... I know, we could have
at 1:26 PM, Brian Di Palma off...@gmail.com wrote:
Sorry for the OT message.
On Tue, Jun 11, 2013 at 6:22 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
We don't have interfaces ... I know, we could have mixins though,
compatible
with @@things too.
The concepts of Mixins has
at 5:48 PM, Dmitry Soshnikov
dmitry.soshni...@gmail.com wrote:
On Tue, Jun 11, 2013 at 5:33 PM, Brendan Eich bren...@mozilla.com wrote:
Brian Di Palma wrote:
Sorry for the OT message.
On Tue, Jun 11, 2013 at 6:22 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
We don't have
Rick talked about a third argument but if that won't exist I like multiple
sources too.
It's also more suitable as Object.mixin(target, ...[source1, source2,
source3]) for predefined collections of mixins to reuse
+1 here
On Thu, Jun 13, 2013 at 3:57 PM, Dmitry Soshnikov
Seliger peter.seli...@googlemail.com
wrote:
If one thinks about how Andrea Giammarchi might have come up
with his already reliable implementation of [Object.mixin] ...
[
https://github.com/WebReflection/object-mixin/blob/master/src/object-mixin.js
]
... the need for changing the order
I think that's possible since the beginning of the time ... we just need
to be a bit more pragmatic with what's available.
Examples here:
http://webreflection.blogspot.com/2012/11/my-name-is-bound-method-bound.html
summarized as
```javascript
Generic.prototype.bound = function (methodName) {
can you try to hot-fix that via `with(values.values=values)` ?
On Tue, Jun 18, 2013 at 2:59 PM, Brandon Benvie bben...@mozilla.com wrote:
On 6/17/2013 6:30 PM, Brandon Benvie wrote:
On 6/17/2013 4:33 PM, Jason Orendorff wrote:
Firefox added Array.prototype.values() and immediately ran into
. And so, ultimately,
myself.
/be
Allen Wirfs-Brock wrote:
On Jun 18, 2013, at 3:05 PM, Brandon Benvie wrote:
On 6/18/2013 3:02 PM, Andrea Giammarchi wrote:
can you try to hot-fix that via `with(values.values=values)` ?
That probably works, but it matters little since the hazard
on 3.1.1-10 AFAIK `Object.preventExtension({})` makes __proto__ immutable.
Since `Object.freeze({})` includes that `preventExtension` call, immutable
should be so no `y` inherited there.
On Thu, Jul 4, 2013 at 3:10 PM, David Bruant bruan...@gmail.com wrote:
Hi,
So, there are standard tests
Just a humble attempt to propose some addiction to the `Object.prototype` I
already know many will kill me for even trying to ...
**tl;dr** - everything proposed can be already tested through this utility
called [eddy.js](https://github.com/WebReflection/eddy#event-driven-js)
### Event Target
my implementation works already with `DOM` nodes and browser environment,
including `window`.
I've also already written an `EventTarget` mixin object but in my case I'd
use that via `Object.mixin(Object.prototype, EventTarget);` 'cause almost
every object I use in my logic should be observed or
401 - 500 of 1535 matches
Mail list logo
