On 7 October 2011 17:47, David Herman wrote:
> I don't think we can get away with repurposing _ as a pattern sigil, since
> it's already a valid identifier and used by popular libraries:
>
> http://documentcloud.github.com/underscore/
>
> In my strawman for pattern matching, I used * as the "
On Fri, Oct 7, 2011 at 12:13 PM, Allen Wirfs-Brock wrote:
>
> On Oct 7, 2011, at 9:23 AM, Axel Rauschmayer wrote:
>
> ...
>
>
>
>> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
>> Object.copyOwnTo(source, target) to the name “extend” (which, to me,
>> suggests inheritance).
On Oct 7, 2011, at 9:23 AM, Axel Rauschmayer wrote:
> ...
>>
>> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
>> Object.copyOwnTo(source, target) to the name “extend” (which, to me,
>> suggests inheritance).
>>
I isn't clear from the attribution who said the followin
On Oct 7, 2011, at 9:13 AM, Juan Ignacio Dopazo wrote:
>
> On Fri, Oct 7, 2011 at 12:34 PM, Axel Rauschmayer wrote:
> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
> Object.copyOwnTo(source, target) to the name “extend” (which, to me, suggests
> inheritance).
>
Just
On Fri, Oct 7, 2011 at 5:23 PM, David Herman wrote:
> I mostly have a similar approach in mind for tail calls. Precise about the
> interface, imprecise/informative about the implementation requirements. For
> WeakMaps, that means a well-defined API with informal English describing the
> expectati
On Fri, Oct 7, 2011 at 11:08 AM, Axel Rauschmayer wrote:
>
>> I don’t see a simple way of “fixing” (property descriptors do have their
>>> uses) Object.create().
>>>
>>
>> Just allow the second argument to be property descriptor *or* object.
>>
>>
>> Problem: property descriptors are indistinguis
(I'm starting a little late on a long thread so sorry if I repeat things that
have already been said.
On Oct 7, 2011, at 1:50 AM, John-David Dalton wrote:
> On Fri, Oct 7, 2011 at 10:17 AM, Jake Verbaten wrote:
>> Object.extend is the only method I shim on every es5 project, so +1
>>
>> Howeve
> From: Allen Wirfs-Brock
> Subject: Re: Grawlix
> Date: October 7, 2011 19:56:23 GMT+02:00
> To: Quildreen Motta , John J Barton
>
> Cc: es-discuss@mozilla.org
> For example, we were looking for a more concise way to express
> obj = Object.defineProperty({}, 'length', {value: 3}); //note
> The object |obj| has a property |foo|; the object |proto| has a property
> |foo|. The string "foo" appears as property names in two different objects.
> I don't understand what problem this will cause for developers. The object
> |obj| does not have duplicate properties, it has a unique value
On Oct 6, 2011, at 4:25 PM, Quildreen Motta wrote:
> On 06/10/11 19:56, John J Barton wrote:
>> Recent syntax discussions head in a completely different direction,
>> introducing a seemingly large number of new symbols resulting in code that
>> isn't readable by current JS, Java, or C devs. Ins
On Fri, Oct 7, 2011 at 10:04 AM, Axel Rauschmayer wrote:
> Sorry to be dense, but I still don't get it. How can an object have
> duplicate properties? I understand that own properties override properties
> on prototypes.
>
>
> When you look at the object literal
> var source = { foo: 123 };
2011/10/7 John J Barton
>
>
> On Fri, Oct 7, 2011 at 9:16 AM, Quildreen Motta wrote:
>
>> 2011/10/7 John J Barton
>>
>>>
>>>
>>> On Fri, Oct 7, 2011 at 8:34 AM, Axel Rauschmayer wrote:
>>>
If you do something like
var fuz = Object.extend(foo, {paper:'in', shoes:'my'});
T
> Again I'll ask you to consider that fuz.bar() should work. That is what
> extend means. How can we solve this?
It’s possible that you are actually looking for mixins:
http://javascriptweblog.wordpress.com/2011/05/31/a-fresh-look-at-javascript-mixins/
One possible solution is to do 2 extends:
On Fri, Oct 7, 2011 at 9:16 AM, Quildreen Motta wrote:
> 2011/10/7 John J Barton
>
>>
>>
>> On Fri, Oct 7, 2011 at 8:34 AM, Axel Rauschmayer wrote:
>>
>>> If you do something like
>>> var fuz = Object.extend(foo, {paper:'in', shoes:'my'});
>>>
>>> Then fuz will get all properties of Object.
> Sorry to be dense, but I still don't get it. How can an object have duplicate
> properties? I understand that own properties override properties on
> prototypes.
When you look at the object literal
var source = { foo: 123 };
then you have e.g.
"toString" in source === true
"hasO
On Fri, Oct 7, 2011 at 9:23 AM, Axel Rauschmayer wrote:
> If you do something like
>> var fuz = Object.extend(foo, {paper:'in', shoes:'my'});
>>
>> Then fuz will get all properties of Object.prototype, again, as
>> duplicates. In the above, you are clearly most interested in what you see in
On Fri, Oct 7, 2011 at 12:34 PM, Axel Rauschmayer wrote:
> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
> Object.copyOwnTo(source, target) to the name “extend” (which, to me,
> suggests inheritance).
>
>--
> Dr. Axel Rauschmayer
>
> I also think Object.extend sugg
> If you do something like
> var fuz = Object.extend(foo, {paper:'in', shoes:'my'});
>
> Then fuz will get all properties of Object.prototype, again, as duplicates.
> In the above, you are clearly most interested in what you see in the literal
> and those are the own properties.
>
> I do
2011/10/7 Juan Ignacio Dopazo
>
> On Fri, Oct 7, 2011 at 12:34 PM, Axel Rauschmayer
> wrote:
>
>> I would prefer the name Object.copyOwnPropertiesTo(source, target) or
>> Object.copyOwnTo(source, target) to the name “extend” (which, to me,
>> suggests inheritance).
>>
>>--
>> Dr. Axel R
2011/10/7 John J Barton
>
>
> On Fri, Oct 7, 2011 at 8:34 AM, Axel Rauschmayer wrote:
>
>
>> If you do something like
>> var fuz = Object.extend(foo, {paper:'in', shoes:'my'});
>>
>> Then fuz will get all properties of Object.prototype, again, as
>> duplicates. In the above, you are clearly
On Fri, Oct 7, 2011 at 8:34 AM, Axel Rauschmayer wrote:
> *From: *John J Barton
> *Subject: **Re: Object.extends (was Re: traits feedback)*
> *Date: *October 7, 2011 16:49:50 GMT+02:00
> *To: *Quildreen Motta
> *Cc: *John-David Dalton , es-discuss Steen <
> es-discuss@mozilla.org>
>
> Several p
I don't think we can get away with repurposing _ as a pattern sigil, since it's
already a valid identifier and used by popular libraries:
http://documentcloud.github.com/underscore/
In my strawman for pattern matching, I used * as the "don't-care" pattern:
http://wiki.ecmascript.org/dok
> From: John J Barton
> Subject: Re: Object.extends (was Re: traits feedback)
> Date: October 7, 2011 16:49:50 GMT+02:00
> To: Quildreen Motta
> Cc: John-David Dalton , es-discuss Steen
>
>
> Several people advocate Object.extend() that copies only own properties. I
> don't understand why; I'
> From: David Herman
> Subject: Re: Grawlix
> Date: October 7, 2011 15:54:58 GMT+02:00
> To: John J Barton
> Cc: Douglas Crockford , es-discuss@mozilla.org
>
>
> On this particular issue, I'm inclined to agree -- I think we should be
> extremely sparing with how many new sigils, if any, we int
I mostly have a similar approach in mind for tail calls. Precise about the
interface, imprecise/informative about the implementation requirements. For
WeakMaps, that means a well-defined API with informal English describing the
expectations about memory consumption. For tail calls, it means a we
Hi Andreas,
- Proxy.create: What if the handler passed is not an object? Should we
> throw right away?
>
We think the most sensible thing to do is to call ToObject(handler), which
will throw right away if the handler is not an object.
> - Proxy.create: What if the prototype passed is neither an
Several people advocate Object.extend() that copies only own properties. I
don't understand why; I'll make the case for copying all properties.
At a call site I use, say
foo.bar();
Ordinarily I should not be concerned about details of bar()'s
implementation. In particular I should not be concer
On this particular issue, I'm inclined to agree -- I think we should be
extremely sparing with how many new sigils, if any, we introduce into the
language. You'll notice Brendan has repeatedly said similar things about <| and
.{ for example. Syntax matters.
But I feel like now might be a good t
Fixed, thanks.
Dave, digging his way out of a massive backlog...
On Sep 23, 2011, at 12:18 PM, Axel Rauschmayer wrote:
> http://wiki.ecmascript.org/doku.php?id=harmony:string_extras
> I’ve found a small bug:
>
> String.prototype.endsWith = function(s) {
> var t = String(s);
> return thi
2011/10/7 John-David Dalton
> > As for the functionality, it should just be an n-ary function which
> extends
> > the first object with all the _own_ properties of the other n-1 objects.
> If
> > keys clash give right precedence.
>
> I've used this flavor of extends too (minus the own properties
On Oct 7, 2011, at 6:51 AM, Mikeal Rogers wrote:
>
>
> On Thu, Oct 6, 2011 at 5:08 AM, Brendan Eich wrote:
> On Oct 4, 2011, at 10:52 AM, Mikeal Rogers wrote:
>
> > But, some of them simply double the semantics and syntax in the language
> > without a path to deprecate previous syntax. I'm
On Thu, Oct 6, 2011 at 5:08 AM, Brendan Eich wrote:
> On Oct 4, 2011, at 10:52 AM, Mikeal Rogers wrote:
>
> > But, some of them simply double the semantics and syntax in the language
> without a path to deprecate previous syntax. I'm a big fan of let, but if
> you don't deprecate var we're going
I think you just documented this:
http://www.yafla.com/dforbes/String_Concatenation_and_Immutable_Strings_Speeding_Spidermonkey/
On Fri, Oct 7, 2011 at 2:01 AM, Wes Garland wrote:
> On 6 October 2011 14:09, Tom Schuster wrote:
>>
>> (1) is in fact really good optimized in modern engines. (In c
On Fri, Oct 7, 2011 at 10:17 AM, Jake Verbaten wrote:
> Object.extend is the only method I shim on every es5 project, so +1
>
> However arguments like library X is would break are stupid, remember es6 is
> an opt-in so backwards compat with existing code be damned.
No U! My concern came from seei
34 matches
Mail list logo
