Le 09/11/2011 02:26, Andrew Paprocki a écrit :
On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eichbren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach.
How many run into the wrong |this| (arguments/break/continue/return)? Not
clear. Something to
On Wed, Nov 9, 2011 at 3:40 PM, Jorge jo...@jorgechamorro.com wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for a goto,
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for a goto, given that
there's no (easy)
On Wed, Nov 9, 2011 at 4:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't
On Nov 9, 2011, at 1:15 PM, Dean Landolt wrote:
On Wed, Nov 9, 2011 at 4:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach(
On Wed, Nov 9, 2011 at 4:20 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 1:15 PM, Dean Landolt wrote:
On Wed, Nov 9, 2011 at 4:05 PM, Brendan Eich bren...@mozilla.com wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as
On Nov 9, 2011, at 1:33 PM, Quildreen Motta wrote:
On 09/11/11 19:20, Brendan Eich wrote:
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
With
On Nov 9, 2011, at 1:33 PM, Dean Landolt wrote:
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
Aye, but I suspect that's because many people don't
And if you need to break out of forEach, just, umm, don't use forEach. It's
the wrong tool for the job.
Clearly people like the forEach array extra in conjunction with Object.keys.
With block-lambdas they could have their cake and break from it too (and the
call would be paren-free to
On Nov 9, 2011, at 2:43 PM, Axel Rauschmayer wrote:
Do block-lamdbas count as a fix for the dynamic this problem?
Definitely.
Or are there other plans to get it solved? I would still love to see that
happen, it’s a remarkably subtle source of errors. Could functions adopt the
Should ES.next provide sugar for the recommended pattern? To make it compose
with declarations and destructuring in the for head, it should use a
contextual keyword immediately after 'for':
for own (i in o) {
body
}
This is a small thing but it might pay off in the long run.
On 09/11/2011, at 22:05, Brendan Eich wrote:
On Nov 9, 2011, at 12:40 PM, Jorge wrote:
On 08/11/2011, at 22:17, John J Barton wrote:
Just as a point of comparison, I use this form:
Object.keys(o).forEach( function(key) {
body
});
By the way, isn't that above a(nother) good use case for
Hi everyone,
There is a widespread practice of doing this:
-
for (key in obj) {
if (obj.hasOwnProperty(key)) { … }
}
-
The oft-stated purpose for this pattern is to weed out code that comes
from Object.prototype. The result, though, is that we prevent iteration
Whats wrong with enumeration over own properties?
Object.keys() gets all enumerable own properties in a for .. in loop.
for .. in gets all enumerable properties in prototype chains.
I personally think it's bad practice to have code that enumerates over
properties in the prototype chain. I can't
What’s the use case?
Don’t forget that whenever you set a property, you only ever modify the first
object in the prototype chain.
The “own property” debate mainly exists, because objects are (ab)used as
dictionaries. Then you don’t want inherited entries such as toString.
On Nov 8, 2011, at
On 11/8/11 12:37 PM, Axel Rauschmayer wrote:
What’s the use case?
I thought I gave a pretty reasonable one before, but just in case:
In YUI, it’s impossible to use this otherwise-useful pattern:
-
var base_config = { width: 600px };
…
var my_config = Object.create(base_config);
What’s the use case?
I thought I gave a pretty reasonable one before, but just in case:
Thanks! Shorter is better... ;-)
In YUI, it’s impossible to use this otherwise-useful pattern:
-
var base_config = { width: 600px };
…
var my_config = Object.create(base_config);
You shouldnt store properties on the prototype chain like that. Your
abusing Object.create as a shallow copy. Use a real shallow copy method.
On Nov 8, 2011 7:07 PM, Felipe Gasper fel...@felipegasper.com wrote:
On 11/8/11 12:37 PM, Axel Rauschmayer wrote: What’s the use case?
I thought I gave
On 11/8/11 1:17 PM, Axel Rauschmayer wrote:
What’s the use case?
In YUI, it’s impossible to use this otherwise-useful pattern:
-
var base_config = { width: 600px };
…
var my_config = Object.create(base_config);
my_config.visible = false;
var widget = new Y.Widget(my_config);
-
On Nov 8, 2011, at 11:48 AM, Felipe Gasper wrote:
Actually, have you ever seen a use case of wanting to prevent iteration
through inherited properties *other* than Object.prototype? (Besides using
for..in on Array objects.)
Sure. People make classes by defining function C(){} and decorating
Brendan EichNovember 8, 2011 11:59 AM
On Nov 8, 2011, at 11:48 AM, Felipe Gasper wrote:
Actually, have you ever seen a use case of wanting to prevent iteration through inherited properties *other* than Object.prototype? (Besides using for..in on Array objects.)
Sure. People make
On Nov 8, 2011, at 12:12 PM, Luke Smith wrote:
Sure. People make classes by defining function C(){} and decorating
C.prototype.method1 = function(...){...}, etc. A for-in loop on (new C) will
see all the methods, unlike the case with built-in constructors. That is an
unwanted abstraction
On 11/8/11 2:19 PM, Jake Verbaten wrote:
Flexibility of shared state?
Are you really corrupting the state of defaults at runtime? Do you
really want changes to your default options to propogate to all objects
extending the defaults?
It’s the same thing as redefining a method inherited from a
The recommended practice when writing for-in loops in JS today is to write:
for (i in o) {
if (o.hasOwnProperty(i)) {
body
}
}
Although many JS developers do not follow the recommendation (out of ignorance
or intentionally, doesn't matter).
Should ES.next provide sugar for
On 11/8/11 2:49 PM, Brendan Eich wrote:
Should ES.next provide sugar for the recommended pattern? To make it
compose with declarations and destructuring in the for head, it should
use a contextual keyword immediately after 'for':
for own (i in o) {
/body/
}
This is a small thing but it might
On 11/8/11 2:19 PM, Brendan Eich wrote:
On Nov 8, 2011, at 12:12 PM, Luke Smith wrote:
Sure. People make classes by defining function C(){} and decorating
C.prototype.method1 = function(...){...}, etc. A for-in loop on (new C) will see all the
methods, unlike the case with built-in
On Tue, Nov 8, 2011 at 12:49 PM, Brendan Eich bren...@mozilla.com wrote:
The recommended practice when writing for-in loops in JS today is to write:
for (i in o) {
if (o.hasOwnProperty(i)) {
body
}
}
Although many JS developers do not follow the recommendation (out of
I see two domains for the concept of “own” properties:
1. Meta-programming.
2. Using objects as dictionaries.
Isn’t #2 the majority (at least as far as non-library-programmers are
concerned)? Will the concept become less relevant once we have David Herman’s
dicts?
I also like the Python-style
On Tue, Nov 8, 2011 at 3:49 PM, Brendan Eich bren...@mozilla.com wrote:
for own (i in o) {
*body*
}
This is a small thing but it might pay off in the long run.
This is a very useful feature ... but for better or for worse, also shows
off how much paren-free would help things. for
Yes, I think JS needs something like this. This is new to no one here, but
my main concern with using hasOwnProperty is the loss of performance, so I
think it would be worth exploring more than just syntactic sugar. But I
don't know how realistic it is to hope for that.
for own (i in o) {
body
}
What happened to @iter.keys and 'for (key of keys) {}'?
http://wiki.ecmascript.org/doku.php?id=harmony:iterators
Claus
http://clausreinke.github.com/
http://clausreinke.github.com/js-tools/
___
es-discuss mailing
Le 08/11/2011 08:59, Felipe Gasper a écrit :
Hi everyone,
There is a widespread practice of doing this:
-
for (key in obj) {
if (obj.hasOwnProperty(key)) { … }
}
-
The oft-stated purpose for this pattern is to weed out code that comes
from Object.prototype. The
On 08/11/11 18:49, Brendan Eich wrote:
The recommended practice when writing for-in loops in JS today is to
write:
for (i in o) {
if (o.hasOwnProperty(i)) {
/body/
}
}
Although many JS developers do not follow the recommendation (out of
ignorance or intentionally, doesn't
On 08/11/11 19:19, Axel Rauschmayer wrote:
I see two domains for the concept of “own” properties:
1. Meta-programming.
Could you expand on the use of `own' properties for meta-programming?
I'm afraid I can't really envision it =/
2. Using objects as dictionaries.
Isn’t #2 the majority (at
Le 08/11/2011 21:49, Brendan Eich a écrit :
The recommended practice when writing for-in loops in JS today is to
write:
for (i in o) {
if (o.hasOwnProperty(i)) {
/body/
}
}
As said in the thread your forked from, this practice is often
recommended to not enumerate Object.prototype
I see two domains for the concept of “own” properties:
1. Meta-programming.
Could you expand on the use of `own' properties for meta-programming? I'm
afraid I can't really envision it =/
Whenever you copy properties from one object to another one, you are usually
doing meta-programming
On Tue, Nov 8, 2011 at 1:45 PM, Timmy Willison timmywill...@gmail.com wrote:
Yes, I think JS needs something like this. This is new to no one here, but
my main concern with using hasOwnProperty is the loss of performance, so I
think it would be worth exploring more than just syntactic sugar.
On Nov 8, 2011, at 1:19 PM, Axel Rauschmayer wrote:
I see two domains for the concept of “own” properties:
1. Meta-programming.
2. Using objects as dictionaries.
Thanks, good to focus on use-cases. Both would like shorthand and freedom from
Object.prototype.hasOwnProperty tamper-proofing.
On Nov 8, 2011, at 1:19 PM, Jeremy Ashkenas wrote:
On Tue, Nov 8, 2011 at 3:49 PM, Brendan Eich bren...@mozilla.com wrote:
for own (i in o) {
body
}
This is a small thing but it might pay off in the long run.
This is a very useful feature ... but for better or for worse, also
On Nov 8, 2011, at 1:48 PM, Claus Reinke wrote:
for own (i in o) {
body
}
What happened to @iter.keys and 'for (key of keys) {}'?
Still there, but write it out fully, to compare to the cited text:
import keys from @iter;
for (i of keys(o)) {
body
}
Unless we default-import a
On 08/11/11 20:22, Axel Rauschmayer wrote:
I see two domains for the concept of “own” properties:
1. Meta-programming.
Could you expand on the use of `own' properties for meta-programming?
I'm afraid I can't really envision it =/
Whenever you copy properties from one object to another one,
On Nov 8, 2011, at 2:03 PM, Quildreen Motta wrote:
On 08/11/11 18:49, Brendan Eich wrote:
The recommended practice when writing for-in loops in JS today is to write:
for (i in o) {
if (o.hasOwnProperty(i)) {
body
}
}
Although many JS developers do not follow the
I see two domains for the concept of “own” properties:
1. Meta-programming.
2. Using objects as dictionaries.
Thanks, good to focus on use-cases. Both would like shorthand and freedom
from Object.prototype.hasOwnProperty tamper-proofing.
Isn’t #2 the majority (at least as far as
On Nov 8, 2011, at 2:26 PM, John J Barton wrote:
On Tue, Nov 8, 2011 at 1:45 PM, Timmy Willison timmywill...@gmail.com wrote:
Yes, I think JS needs something like this. This is new to no one here, but
my main concern with using hasOwnProperty is the loss of performance, so I
think it would
On Nov 8, 2011, at 2:26 PM, John J Barton wrote:
On Tue, Nov 8, 2011 at 1:45 PM, Timmy Willison timmywill...@gmail.com wrote:
Yes, I think JS needs something like this. This is new to no one here, but
my main concern with using hasOwnProperty is the loss of performance, so I
think it would
On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eich bren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach.
How many run into the wrong |this| (arguments/break/continue/return)? Not
clear. Something to study.
I was curious so I did some grok-ing
On 08/11/11 21:36, Brendan Eich wrote:
Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach.
How many run into the wrong |this| (arguments/break/continue/return)? Not
clear. Something to study.
Well, I use Object.keys, etc, a lot thorough my code. I can't remember a
On Tue, Nov 8, 2011 at 11:36 PM, Brendan Eich bren...@mozilla.com wrote:
Ignoring performance, a lot of stylish JS hackers use
Object.keys(o).forEach. How many run into the wrong |this|
(arguments/break/continue/return)? Not clear. Something to study.
/be
I personally use `Object.keys()`
On 08/11/11 23:59, Jake Verbaten wrote:
However on average a lot more people will use for ... in with
hasOwnProperty because ES5 environments are rare and a lot of people
avoid the ES5-shim
Do you mean `rare' as in they have to work with the lowest common
denominator (IE)? Because
In the real world IE9 still accounts for almost 50% of browsers. Then
there's another 6% for FF3.6 and another 3% for opera.
As much as I like promoting that you should ignore legacy browsers, for
most people 50% market share is a good enough reason to support them.
On Wed, Nov 9, 2011 at 2:03
Still there, but write it out fully, to compare to the cited text:
import keys from @iter;
for (i of keys(o)) {
body
}
Unless we default-import a standard prelude,
I think we should.
this is a bit much compared to add own as a modifier after for in for/in (not
for/of)
On Nov 8, 2011, at 9:08 PM, Jake Verbaten rayn...@gmail.com wrote:
In the real world IE9 still accounts for almost 50% of browsers. Then
there's another 6% for FF3.6 and another 3% for opera.
Latest Opera builds are 100% ES5.1 compliant. (according to opera dev-rel)
As much as I like
On Nov 8, 2011, at 8:39 PM, David Herman wrote:
Instead of taking a hard-to-use-right form like for-in and partly taming it,
I'd rather suggest people simply move to for-of, and have the default keys
iterator Do The Right Thing and only iterate over own, enumerable property
names (thanks
Let's answer this once we have the module-ized version of the standard library.
Which I've been promising for far too long (mea culpa). Will get started on
this tonight.
Dave
On Nov 8, 2011, at 9:04 PM, Brendan Eich wrote:
On Nov 8, 2011, at 8:39 PM, David Herman wrote:
Instead of taking
On Tue, Nov 8, 2011 at 9:03 PM, Rick Waldron waldron.r...@gmail.com wrote:
Latest Opera builds are 100% ES5.1 compliant. (according to opera dev-rel)
The latest externally visible Opera is Opera 12 alpha build 1116. It is
indeed very close to ES5.1 compliant. But it still fails
On Wed, Nov 9, 2011 at 12:12 AM, Mark S. Miller erig...@google.com wrote:
On Tue, Nov 8, 2011 at 9:03 PM, Rick Waldron waldron.r...@gmail.comwrote:
Latest Opera builds are 100% ES5.1 compliant. (according to opera dev-rel)
The latest externally visible Opera is Opera 12 alpha build 1116.
56 matches
Mail list logo
