On Sun, Sep 18, 2011 at 7:17 AM, Brendan Eich wrote:
>
> The point is that you don't *have* to pass a fresh object literal to each
> constructor call.
>
> /be
>
>
I know Brendan, my point is that I can predict devs will do every time
we'll see
Thanks for other reply, I thought named argumen
nce many libs are
using single object as function argument to obtain similar behavior
fn({a: 1, b: 2})
and back to the "too many objects created due lack of defaults/named
arguments" trap ...
Never mind, this is not for this thread.
Best Regards,
Andrea Giammarchi
On Sun, Sep
p 18, 2011 at 6:26 PM, Brendan Eich wrote:
> On Sep 18, 2011, at 12:09 PM, Andrea Giammarchi wrote:
>
> I know it's the same, for this reason I said it was "shimmable"
>
> New syntax would be fine as long as minifiers won't break everything so ...
> as long as
-brendan-here-was-my-question.html
I would like to thank you in advance for your time and all possible
answers/considerations/questions you may come up with.
Cheers,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@mozilla.org
https
hese years in between will put JavaScript into an even worse position where
JS developers will ask themselves: what is exactly JavaScript ?
Thanks in any case for your answer.
Best Regards,
Andrea Giammarchi
On Tue, Oct 4, 2011 at 6:18 AM, Russell Leggett
wrote:
> On Mon, Oct 3, 2011 at 4:4
ect.freeze || function(o){return o}
;
return function Enum() {
forEach.call(arguments, assign, this);
return freeze(this);
};
}());
var colors = new Enum("red", "green", "blue");
Hope it was useful.
Best Regards,
Andrea Giammarchi
__
free to ask more, if necesary, thanks.
br,
WebReflection
On Tue, Oct 4, 2011 at 3:16 PM, David Bruant wrote:
> Le 03/10/2011 22:49, Andrea Giammarchi a écrit :
>
>> Dear All,
>>while I had the opportunity to ask directly to Brendan Eich this
>> question, I
e but
I'll be happy to show examples you can reuse to simulate new syntax features
:-)
On Tuesday, October 4, 2011, David Bruant wrote:
> Le 04/10/2011 17:03, Andrea Giammarchi a écrit :
>
> David, as I have tweeted before, syntax is a non problem, surely is not a
problem *now*
)
;
var hasOwnProperty = bind(invoke, {}.hasOwnProperty);
hasOwnProperty({key:1}, "key"); // true
call([].slice, [1,2,3], 1); // 2,3
apply([].slice, [1,2,3], [1]); // 2,3
Regards,
Andrea Giammarchi
___
es-discuss mailing list
es-discuss@m
Here again I am not sure how we ended up with this conversation but you can
find a function able to extract properties and methods out of a generic
object:
https://gist.github.com/1264775
It works with jQuery too, as well as arrays, etc etc
Regards,
Andrea Giammarchi
2011 at 11:48 AM, Andrea Giammarchi
> wrote:
> > Here again I am not sure how we ended up with this conversation but you
> can
> > find a function able to extract properties and methods out of a generic
> > object:
> > https://gist.github.com/1264775
> > It
Sorry Russ, I am not sure I got it
On Wed, Oct 5, 2011 at 6:14 PM, Russell Leggett
wrote:
> On Wed, Oct 5, 2011 at 12:04 PM, Andrea Giammarchi
> wrote:
> > with such dynamic language I would never trust much AST
> > This is for realtime, inline, methods and properties s
as Zend Certified Engineer I can say == and === have never been a problem
... also there are cases when I *want* coercion!
var False = new Boolean(false);
if (False) alert("You may say WTF");
if (False == false) alert("I may say feature");
Best Regards,
something like this ? ...
(function () {
function dispatch(callback) {
callback.call(this.r, this.e);
}
function add(callback) {
this.handlers.indexOf(callback) < 0 &&
this.handlers.push(callback);
}
function remove(callback) {
var i = this.handlers.indexOf(callback);
-1 < i && this.ha
I think I removed your text through selection
... apologies
On Sat, Oct 15, 2011 at 7:44 PM, David Bruant wrote:
> Le 15/10/2011 18:26, Andrea Giammarchi a écrit :
>
> something like this ? ...
>
> My email client says that you're responding to my initial message, but you
> ma
the original proof of concept
// problem with variable "event" solved
});
};
var o = Object.asEmitter(Object.create(null));
o.on.whatever.add(callback);
o.on.whatever({type: "whatever"});
br
On Sat, Oct 15, 2011 at 8:19 PM, David Bruant wrote:
> Le 15/10/2011 19:52, An
Just because in this ml there are many engineers involved in JS engines
optimizations ... this is a "what if..." post, feel free to comment it or
hopefully take some hint out of it:
http://webreflection.blogspot.com/2011/10/missing-tool-in-scripting-world.html
Best Regards
note ?
Thanks
On Sun, Oct 16, 2011 at 3:23 PM, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 16, 2011 at 8:52 AM, Andrea Giammarchi
> wrote:
> > Just because in this ml there are many engineers involved in JS engines
> > optimizations ... this is a "what if..." post
rams are stored or transmitted for subsequent use on multiple
> underlying architectures.
>
> *From: *Andrea Giammarchi
> *Subject: **The Missing Tool In Scripting World*
> *Date: *October 16, 2011 14:52:47 GMT+02:00
> *To: *"es-discuss@mozilla.org"
>
>
>
code ... AFAIK not possible right now
On Sun, Oct 16, 2011 at 9:15 PM, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 16, 2011 at 12:05 PM, Andrea Giammarchi
> wrote:
> > not natively, and not in the optimized way C or C++ do
>
> This is not correct -- SBCL and Larceny (and
comparison.
Any thought on this will be appreciated and apologies if this has been
discussed already ( so a quick answer on "how it's going to be" would be
more than enough )
Best Regards,
Andrea Giammarchi
___
es-discuss mailing
check, returning the added generic value would be more
than helpful for many common tasks.
mySingleSet.add(myGenericObject).methodCallOnAdd(/*args*/);
Thanks for any sort of clarification.
Best Regards,
Andrea Giammarchi
___
es-discuss mailing li
gument is anything other
> than NaN, 0, and -0.
>
> On Thu, Jun 14, 2012 at 3:24 PM, Andrea Giammarchi
> wrote:
> > Hello everybody,
> > I am not sure about the status of this subject but I find quite
> > inconsistent the fact we cannot trust Array#indexOf when it come
i = indexOf.call(this, value);
}
return i;
}
maybe somebody else should implement something similar to avoid N
Object.is(a, b) checks within the loop ...
cheers
On Thu, Jun 14, 2012 at 1:59 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> This is basically what
d(generic)) {
> > // first time generic has been set
> > } else {
> > // generic was there already
> > }
> >
> > My Take:
> > while the returning boolean could be considered superfluous, since it
> > could be implemented in Set#delete(generic) or
if anyone is also interested I have filed these three bugs:
https://code.google.com/p/chromium/issues/detail?id=132741
https://code.google.com/p/chromium/issues/detail?id=132742
https://code.google.com/p/chromium/issues/detail?id=132744
On Thu, Jun 14, 2012 at 2:28 PM, Andrea Giammarchi
I have written tests already so if I have to change few things and push to
test262 just let me know, thanks.
br
On Thu, Jun 14, 2012 at 2:46 PM, David Bruant wrote:
> Le 14/06/2012 12:56, Mark S. Miller a écrit :
>
> On Thu, Jun 14, 2012 at 6:00 PM, Andrea Giammarchi
>> w
y Vojčík wrote:
>
>
> Andrea Giammarchi wrote:
>
>> just in case ... this is my internal function
>>
>> // var is = Object.is || properShim
>> // var indexOf = [].indexOf || shortShim
>> // var i;
>> function betterIndexOf(value) {
>>
just in case, since mentioned here ...
https://github.com/WebReflection/JSONH#javascript-and-native-json-escape-problems
to make stringified JSON safer so that
JSONH.stringify(data).replace(
/\u2028|\u2029/g,
function (m) {
return "\\u202" + (m === "\u2028" ? "8" : "9");
})
I think these things are really easy to implement and fast enough in
current JS engines, e.g.
function cube() {
return cube.reduce.call(arguments, cube.iterator, 0);
}
cube.reduce = [].reduce;
cube.iterator = function (p, c) {
return p + Math.pow(c, 3);
};
alert(cube(2, 3)); // 35
br
On T
just seen it, looks like an improved alternative to the good old, non
standard, Object.prototype.watch ... but
1. records are not "struct like", properties might be or might not be
there rather than being there with undefined values ... is this heading to
not optimal performances in V8 an
case for the reply.
br
On Tue, Aug 14, 2012 at 11:30 AM, Alex Russell wrote:
>
> On Tue, Aug 14, 2012 at 10:33 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> just seen it, looks like an improved alternative to the good old, non
>> standar
ue, Aug 14, 2012 at 11:04 PM, Erik Arvidsson
wrote:
> On Tue, Aug 14, 2012 at 5:31 PM, Andrea Giammarchi
> wrote:
> > if fixed-ish shape is not a performance issue then is fine, still I would
> > put in this fixed-ish shape a currentValue property, not only the
> oldValue
&
to enable a Java Applet in order to
have better precision ( without considering that both binding and callback
are more expensive than any +new Date call )
Thanks for any sort of answer.
Best Regards,
Andrea Giammarchi
___
es-discuss mailing list
console.log(t);
} catch(o_O) {
try {
alert(t);
} catch(o_O) {
print(t);
}
}
//*/
br,
Andrea Giammarchi
On Thu, Aug 16, 2012 at 12:45 PM, David Bruant wrote:
> What about high resolution time?
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.h
fair enough :D
On Thu, Aug 16, 2012 at 1:28 PM, David Bruant wrote:
> Le 16/08/2012 14:02, Andrea Giammarchi a écrit :
>
> looks like the result would be the same obtained via preciseTime() *
>> 100 ... I just wonder why this is a W3C draft rather than a ECMAScript
&g
ass, super and stuff, but
that's not really what nowadays web applications need, Object.observe is,
and this is, of course, just my opinion.
br,
Andrea Giammarchi
On Thu, Aug 16, 2012 at 8:17 PM, Rafael Weinstein wrote:
> I've created a bunch of cool demos and a video which at
the Notifier is lazily instantiated and I believe not enumerable so
JSON.stringify should ever expose this property.
Moreover, it does not look like there is a {}.__notifier__ property
anywhere, Object.getNotifier(obj) is required indeed so a WeakMap that
relates the obj, and its notifier, cannot
typo: should *never* expose the not enumerable property
On Fri, Aug 17, 2012 at 10:57 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> the Notifier is lazily instantiated and I believe not enumerable so
> JSON.stringify should ever expose this property.
>
> Mor
hijacking attacks but tremendous performance impact ( if a notifier has to
automatically create a notifier up to the proto chain until the null
prototype ... a non-sense, imho )
On Fri, Aug 17, 2012 at 11:01 AM, gaz Heyes wrote:
> On 17 August 2012 10:57, Andrea Giammarchi wrote:
>
>>
You can observe the Object.prototype same you can define setters and stuff
there ... observing it won't affect literals or new object creation since
it works with own properties.
On Fri, Aug 17, 2012 at 2:46 PM, gaz Heyes wrote:
> On 17 August 2012 14:31, Andrea Giammarchi wrote:
&
The Object owner is a bit inconsistent concept in JS + DOM world.
document.body.innerHTML = 'link';
is a very basic example ...
1. was the user owning the document.body ? I don't think so, body is
created in any case even if not specified in the markup
2. was the user able to set mutati
but then, as you write, if I decide to expose an object or I can reach an
object and then use Object.observe there is no ownership problem since
whoever let me reach that object didn't want to block me doing so ... also
because the Object.freeze(exposedObject) is an easy solution where
internally,
the non eval solution for ES3 is
var global = function(){return this}();
and not with eval ...
In ES5 usually window is not writable/configurable but enumerable so
theoretically you can rely in the `window` object unless your code is not
evaluated through eval inside a function with a window var
Sorry guys, I just wonder if there's any outcome here ... rather than keep
proposing something else :-)
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
+1 for makeObservable
On Fri, Aug 31, 2012 at 10:41 AM, François REMY
wrote:
> From: Rick Waldron
>> Nit: "Object.makeBindable" sounds like: "prepare this for bindability",
>> but "bind" is already a concept in the language, where
>> Function.prototype.bind creates a new function object from an e
OT: Really David ... you use a french keyboard too? I can't imagine me
programming with an italian layout :D
I believe the question was about fixing or spec'ing the behavior which
seems reasonable.
We already decided to break the web with all new syntax stuff and "use
strict" directive so if ES7
... or the ability to boost up a lot JIT and performances ... but I agree
on the non trivial, rich in ugly JS corner cases too, e.g. string as
primitive VS String as instanceof
On Tue, Sep 25, 2012 at 10:23 AM, Andreas Rossberg wrote:
> On 24 September 2012 20:53, Dmitry Soshnikov
> wrote:
> > I
M, Alex Russell wrote:
> Perhaps, but it's easy to be too naive about what VMs do (and don't do).
> Best to design for semantics with performance in mind, not the other way
> around.
>
> In any case, would you be looking for nominal or structural type tests
> here?
>
>
then nominal will be? :)
On Tue, Sep 25, 2012 at 3:37 PM, Andreas Rossberg wrote:
> On 25 September 2012 15:31, Andrea Giammarchi
> wrote:
> > That's a hell of a question ... shapes speaking I'd say structural, since
> > AFAIK shapes are those boosted up more, isn&#x
t again,
> backing a type system into ES isn't something to do lightly. It has huge
> consequences that extend well beyond the grammar changes.
>
>
> On Tue, Sep 25, 2012 at 3:59 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> then nomi
then how about forgetting ducks and classes, going typeof without implicit
cast?
function doStuff(i:number, key:string, u:undefined, b:boolean,
fn:function):object {}
where `null` will still be under the object type.
Would this be a decent compromise or a pointless effort for no benefits?
On T
Dmitry I think in this view the proposal having "primitives" rather than
instanceof makes more sense and is probably what you need, right?
string s won't accept instanceof String, that's what you want ... 'cause
you don't want pointless objects wrappers around neither, isn't it?
You want function
well ... I was asking indeed why that was not even an option ... is not
half backed being typeof the most used check ever for arguments and
variables but I got your point :-)
br
On Tue, Sep 25, 2012 at 8:54 PM, Brendan Eich wrote:
> Andrea Giammarchi wrote:
>
>> then how about forg
surely there's nothing to rush about, we survived already until now, no
reason to go for a quick solution and mine was just a proposal based on the
fact that most of the time contracts are based on primitives.
However, If the problem is typeof null then ES should fix that first but
AFAIK it came b
not really, you can have frozen top or stuff like that ... but the point
is: why would you use same origin frames and, if you do, why not using
postMessage that won't have any instanceof Array problem.
An example/realworld case that could not do it differently? I don't
remember one
On Wed, Sep 26
it would be stupid to code like that but it makes sense since it has
basically always been like that :)
function f(a) {
// var a superflous ... still works
var a, b = a, a = 3, c = a;
return a+" "+b+" "+c;
}
On Thu, Sep 27, 2012 at 5:19 PM, Allen Wirfs-Brock wrote:
> Consider
>
>functi
I did not mean to offend anyone ... it just looked weirdest, non-sense,
function contract, ever :D
Apologies and thanks for describing **even** these details in
specifications, appreciated!
On Thu, Sep 27, 2012 at 5:41 PM, Allen Wirfs-Brock wrote:
>
> On Sep 27, 2012, at 9:31 AM,
as described here
function f(a) {
// var a superflous ... still works
var a, b = a, a = 3, c = a;
return a+" "+b+" "+c;
}
same / equivalent result
On Thu, Sep 27, 2012 at 6:09 PM, Jason Orendorff
wrote:
> On Thu, Sep 27, 2012 at 11:19 AM, Allen Wirfs-Brock
> wrote:
> >function f(a, b
t;
>>
>> On Sep 27, 2012, at 9:31 AM, Andrea Giammarchi wrote:
>>
>> > it would be stupid to code like that but it makes sense since it has
>> basically always been like that :)
>>
>> A big part of of my job is specifying what stupid code does.
>>
>
you have a getClass mechanism but no getImplementedInterfaces one ... also
never thought about xpcomponents but at least I would speed up that
function via {}.toString.call rather than that double lookup per each
call :-)
However, xpconnect is a very specific use case so you might decide to
R
But then why such "encouragement"
https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ ? ( Proxy
paragraph )
If __noSuchMethod__ is wrong, what's the point of suggesting a way to
simulate it through proxies?
Moreover, what's the point to mark it wrong if many developers asked for it?
I a
>
>
> On Wed, Oct 24, 2012 at 5:16 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> But then why such "encouragement"
>> https://brendaneich.com/2012/10/harmony-of-dreams-come-true/ ? ( Proxy
>> paragraph )
>>
>> If __noSuch
how about
`someObject = null;`
rather than delete someObject;
?
free'ing' an object is like dealing with GC ... I think you would rather
stay away from it and track references, and free them, as much as you can :)
On Thu, Oct 25, 2012 at 4:16 PM, Isaac Schlueter wrote:
> It'd be really nice
if you are holding it already plus you don't know what happens after that
assertFree(obj) call I am not sure about the value of this assertion.
On Thu, Oct 25, 2012 at 6:04 PM, Alex Russell wrote:
> This use-case is usually what weak refs get pressed into service for. But
> I think that answering
+1 for reusable callbacks, these make a lot of sense even if not always
used out there from lazy devs
said that, what is the status of size ? it was in then I have removed it
from es6-collections fast polyfill now is back again ?
Moreover, will be size, for common naming convention purpose, be us
g.prototype hack will be to put a "points"
getter ( or "size", why not ) in order to retrieve the length in points
rather than chars. size() is quite common, hence the question.
>
> Andrea Giammarchi wrote:
>
>> Moreover, will be size, for common naming conv
Just wondering if this is actually meant/expected, I am talking about the
example here:
http://wiki.ecmascript.org/doku.php?id=harmony:observe#example
and the fact it should show something in console while in my opinion that
should show nothing since the Object.unobserve is called in the same "ti
any given
> object. The asynchrony has to do with having changeRecords delivered
> -- that happens asynchronously.
>
> I don't understand the leak you are describing. Perhaps you can give a
> concrete example and how it goes wrong.
>
> On Thu, Nov 1, 2012 at 9:32 PM, Andre
u are worried about callbacks being delivered with
> changeRecords pointing to objects that they have stopped observing.
> This can and will happen. It's just something that users of the API
> need to understand. It doesn't strike me as a problem, but perhaps I'm
> mi
I would add ... am I the only one that does not create a new object per
each defined property ? I am recycling descriptor.value like hell, I wonder
if anyone else out there is doing the same.
On Fri, Nov 2, 2012 at 1:31 AM, Tom Van Cutsem wrote:
> 2012/11/1 David Bruant
>
>> The constructor I
I was wondering the same ... if `contains()` is the new indexOf then why
other collections are using `has()` ... I like has() more but it might be
me lazy typer ... still it should be consistent.
On Fri, Nov 2, 2012 at 9:14 AM, Rick Waldron wrote:
>
>
> On Fri, Nov 2, 2012 at 11:25 AM, Allen Wi
iptor. I define almost
everything through this pattern that when I've seen an extra constructor
around I've freaked out :D
On Fri, Nov 2, 2012 at 9:35 AM, Allen Wirfs-Brock wrote:
>
> On Nov 2, 2012, at 9:29 AM, Andrea Giammarchi wrote:
>
> I would add ... am I the only one
+1 ... but funny that for Strings I would naturally use "mychunk" in
mystring rather than mystring.has("mychunk") I believe contains comes
from XSL, isn't it? Was it W3C suggestion or what?
On Fri, Nov 2, 2012 at 10:20 AM, Erik Arvidsson wrote:
> On Fri, Nov 2, 2012 at 12:30 PM, Mark S. Mil
we are used to
`if (!arr.length) { }`
so I don't see much different with collections and `size()`
Said that, I have bad feelings when I read "empty()" thinking about all
other set of inconsistencies famous in PHP world :-)
On Fri, Nov 2, 2012 at 10:26 AM, Nicholas C. Zakas <
standa...@ncz
fair enough, but I want to know what I am seeing is recorded and the TV is
switched off ... how? Flagging records? Flagging objects? Via getNotifier ?
On Fri, Nov 2, 2012 at 11:56 AM, Erik Arvidsson wrote:
> On Fri, Nov 2, 2012 at 12:22 PM, Andrea Giammarchi
> wrote:
> > How
I actually agree on this, but Set.has() is misleading then, imho. Shouldn't
be specified that `has()` is key related and `contains()` is value related?
Also a "magic" Object.has(obj, key) with smart obj recognition and
Object.contains(obj, value) would be probably cool
On Fri, Nov 2, 2012 at 2:30
I see security problems all over ... you own your function, you can make it
"pure" or serializable ... you don't know your function, I believe there's
no way you want that unknown function to be executed in your own sandbox
opening doors for any sort of attack, i.e. ... this is pure, no outer scope
vas then try to
access/modify them which results in security exception if image is not
trusted ) ... Elsewhere, 2009, if anyone is interested:
http://webreflection.blogspot.com/2009/07/elsewhere-sandboxes-have-never-been.html
On Mon, Nov 5, 2012 at 1:28 PM, David Bruant wrote:
> Le 05/11/
o be able to add own
namespace in the list and I believe making a white list modifiable from
anyone is again a security problem.
On Mon, Nov 5, 2012 at 2:12 PM, Mark S. Miller wrote:
>
> On Mon, Nov 5, 2012 at 1:11 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
&g
my point on namespaces was this one: everyone want's to use jQuery, then
underscore, then this or that ... then you need to be able to modify the
white list.
On Mon, Nov 5, 2012 at 2:28 PM, Mark S. Miller wrote:
>
>
>
> On Mon, Nov 5, 2012 at 2:22 PM, Andrea Giammarchi &
that wants ...
On Mon, Nov 5, 2012 at 2:35 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> my point on namespaces was this one: everyone want's to use jQuery, then
> underscore, then this or that ... then you need to be able to modify the
> white list.
>
>
unexpected, IMHO
On Tue, Nov 6, 2012 at 9:44 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> I found this behavior quite hilarious and I wonder if this is expected.
> It is also new somehow 'cause node.js < 0.8.1 wasn't behaving like this.
>
> I am ta
so this mean that freezing a Contructor.prototype to enforce/ensure nobody
can change runtime that prototype will result in unusable code as we know,
right? Or we should never pre define properties that should be changed
runtime? Second one works and stink at the same time.
I preferred the old V8
a...@rauschma.de
> Home: http://rauschma.de
> Blog: http://2ality.com
>
> On 07.11.2012, at 00:31, Andrea Giammarchi
> wrote:
>
> so this mean that freezing a Contructor.prototype to enforce/ensure nobody
> can change runtime that prototype will result in unusable code as we kn
so it's not just me ... let's see if I can contribute a bit here with my
thoughts ( I think I cannot edit that page )
Why it's bad for efficiency
Frozen objects can be considered similar to C structs and optimized by ES
engines as such.
Being prototypal inheritance based on objects, sh
You are thinking in "constructors" ... I think in
`Object.create(fromObject)` where there's no initialization and defaults
are more than welcome. There is no reason to assign all possible defaults
per each instance creation ... it's "costy" so why would you ? I prefer
assign/overwrite properties wh
that's a feature ... and if you do that either you know what you are doing
or you need to know what you are doing.
Shared objects are powerful, not a problem .. not the problem here, imho
On Wed, Nov 7, 2012 at 9:27 AM, Kevin Smith wrote:
>
>> Any other reasons for why they are discouraged?
>>
same would be for data methods
On Wed, Nov 7, 2012 at 9:52 AM, John J Barton
wrote:
>
>
>
> On Wed, Nov 7, 2012 at 9:17 AM, Axel Rauschmayer wrote:
>
>> In theory, one can use prototype properties to provide default values for
>> instance properties.
>>
>
> In practice instances are free to wri
reason to avoid properties in the prototype,
imho
On Wed, Nov 7, 2012 at 10:02 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> same would be for data methods
>
>
> On Wed, Nov 7, 2012 at 9:52 AM, John J Barton > wrote:
>
>>
>>
>>
>>
if it's about iterating you have forEach which does not iterate over non
assigned indexes ... this looks like you want a new feature with an ES5
method as filter is so that you can use an ES3 for loop after ...
I mean, you have forEach, map, etc to iterate valid indexes, why would you
need that?
this default
behavior, I guess, that's why I think is not worth it.
br
On Mon, Nov 12, 2012 at 1:29 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> if it's about iterating you have forEach which does not iterate over non
> assigned indexes ... this looks like
this is really easy to fix via code but I would rather propose an
Array#compact() or Array#dense() method rather than changing everything
else (included shims/polyfills)
I really don't remember when it happened last time that I had to deal with
such kind of Arrays ... and this made already every p
Array.prototype.some ?
On Mon, Nov 12, 2012 at 6:07 PM, Alex Vincent wrote:
> I've been wondering for a while if it would be a good idea to add an
> argument to Array.prototype.filter, for a maximum number of matches. For
> example, if I have a thousand-element array and I only want three matc
wait, I might have misunderstood your problem ... so you want to stop
iterating, right ?
When that is the case, you can simply drop the iteration like this:
myArray.slice().filter(function (value, index, original) {
// do your stuff
if (conditionSatisfied) {
original.length = 0;
}
});
tically, I think Array.prototype.some would be equivalent to my
> suggested Array.prototype.filter(callback, thisObj, 1);
>
>
> On Tue, Nov 13, 2012 at 12:33 PM, Brendan Eich wrote:
>
>> Andrea Giammarchi wrote:
>>
>>> wait, I might have misunderstood your problem ... so you want
12 at 3:33 PM, Brendan Eich wrote:
>
>> Andrea Giammarchi wrote:
>>
>>> wait, I might have misunderstood your problem ... so you want to stop
>>> iterating, right ?
>>>
>>> When that is the case, you can simply drop the iteration like this:
>>
I wonder if there is any plan to allow a chunk of code to disable for its
own closure purpose a previously called "use strict"; directive.
This is about the ability to use, when not possible otherwise, some good
old feature such caller which is impossible to replicate when use strict is
in place.
my typo ... I am NOT talking about callee, I am talking about caller which
is NOT a misfeature specially when it comes to debug and stack trace.
On Thu, Nov 15, 2012 at 11:55 AM, Oliver Hunt wrote:
>
> On Nov 15, 2012, at 11:44 AM, Andrea Giammarchi <
> andrea.giammar...@gmai
gotcha about eval ... but indeed eval makes things slower in any case,
right?
On Thu, Nov 15, 2012 at 11:58 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> my typo ... I am NOT talking about callee, I am talking about caller which
> is NOT a misfeature specially when
301 - 400 of 1636 matches
Mail list logo
