Re: traits feedback

2011/10/10 Dean Landolt > > On Mon, Oct 10, 2011 at 4:13 PM, John J Barton < > johnjbar...@johnjbarton.com> wrote: >> >> On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem wrote: >> >>> The traits philosophy is that, when merging objects, you want to see name >>> clashes flagged as exceptions (to pr

Re: traits feedback

On Mon, Oct 10, 2011 at 5:06 PM, John J Barton wrote: > > > On Mon, Oct 10, 2011 at 1:45 PM, Dean Landolt wrote: > >> >> >> On Mon, Oct 10, 2011 at 4:13 PM, John J Barton < >> johnjbar...@johnjbarton.com> wrote: >> >>> >>> >>> On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem wrote: >>> 2011/1

Re: traits feedback

On Mon, Oct 10, 2011 at 1:45 PM, Dean Landolt wrote: > > > On Mon, Oct 10, 2011 at 4:13 PM, John J Barton < > johnjbar...@johnjbarton.com> wrote: > >> >> >> On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem wrote: >> >>> 2011/10/6 Brendan Eich >>> On Oct 5, 2011, at 9:02 PM, John J Barton wr

Re: traits feedback

On Mon, Oct 10, 2011 at 4:13 PM, John J Barton wrote: > > > On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem wrote: > >> 2011/10/6 Brendan Eich >> >>> On Oct 5, 2011, at 9:02 PM, John J Barton wrote: >>> >>> The traits philosophy is that, when merging objects, you want to see name >> clashes flag

Re: traits feedback

On Mon, Oct 10, 2011 at 11:59 AM, Tom Van Cutsem wrote: > 2011/10/6 Brendan Eich > >> On Oct 5, 2011, at 9:02 PM, John J Barton wrote: >> >> The traits philosophy is that, when merging objects, you want to see name > clashes flagged as exceptions (to prevent inadvertent overriding). That's > why

Re: traits feedback

2011/10/6 Brendan Eich > On Oct 5, 2011, at 9:02 PM, John J Barton wrote: > > Trait.create() parallels Object.create() and I gather that > Trait.compose() resembles proposed Object.extend(). I wonder if the > traits.js 'parallel-universe' could be applied to Trait.resolve(). In my > experience re

Re: Object.extends (was Re: traits feedback)

> Sure, Object.create(proto).extend({k1:v1, ... kN:vN}). > > If you want to make that one method instead of two, a new Object.createSimple > or better name would be needed. Such a method would be very useful independently of this use case! I would also love to have turn Object.defineProperties

Re: Object.extends (was Re: traits feedback)

On Oct 7, 2011, at 11:39 AM, John J Barton wrote: > 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.

Re: Object.extends (was Re: traits feedback)

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).

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

(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

Re: Object.extends (was Re: traits feedback)

> 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

Re: Object.extends (was Re: traits feedback)

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 };

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

> 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:

Re: Object.extends (was Re: traits feedback)

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.

Re: Object.extends (was Re: traits feedback)

> 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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

> 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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

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

Re: Object.extends (was Re: traits feedback)

> From: Andrew Dupont > JJB has it mostly right. When Sam wrote Object.extend (which was originally > Object.prototype.extend), it didn't use hasOwnProperty; my guess is that Sam > didn't know about it, because most of us were JavaScript amateurs back in the > day, including myself. When I join

Object.extends (was Re: traits feedback)

On Thu, Oct 6, 2011 at 8:04 PM, Andrew Dupont wrote: > > (Keep in mind that the 80% use-case for this sort of thing is merging > default options with user-supplied options, at least in the code I write. > That's a simple case that usually involves merging two plain objects without > interesting __

Re: traits feedback

On Oct 6, 2011, at 12:30 PM, Brendan Eich wrote: > My point was that your "PrototypeJS and Firebug pre-date .hasOwnProperty()" > chronology was wrong. Object.prototype.hasOwnProperty was around since ES3. > It was not used in Prototype, but on the other hand, the "never extend > Object.prototy

Re: traits feedback

On Thu, Oct 6, 2011 at 10:30 AM, Brendan Eich wrote: > On Oct 6, 2011, at 8:06 AM, John J Barton wrote: > > On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich wrote: > >> On Oct 5, 2011, at 9:02 PM, John J Barton wrote: >> >> > PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), >

Re: traits feedback

On Oct 6, 2011, at 8:06 AM, John J Barton wrote: > On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich wrote: > On Oct 5, 2011, at 9:02 PM, John J Barton wrote: > > > PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), > > hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 200

Re: traits feedback

2011/10/6 John J Barton > > > On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich wrote: > >> On Oct 5, 2011, at 9:02 PM, John J Barton wrote: >> >> > PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), >> >> hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug

Re: traits feedback

On Wed, Oct 5, 2011 at 10:37 PM, Brendan Eich wrote: > On Oct 5, 2011, at 9:02 PM, John J Barton wrote: > > > PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), > > hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug is > post-y2k. > > > > so their implem

Re: traits feedback

On Thu, Oct 6, 2011 at 5:44 AM, Brendan Eich wrote: > [...] We want only "own" properties, including private-name-object-keyed > ones. > I agree that ".{", being a special form with a literal to the right, should "copy" private-name keyed properties from right to left. However, doing so for a no

Re: traits feedback

On Oct 5, 2011, at 9:02 PM, John J Barton wrote: > PrototypeJS (and Firebug) pre-date Object.keys() and .hasOwnProperty(), hasOwnProperty was in ES3 in 1999. PrototypeJS is IIRC 2005-era. Firebug is post-y2k. > so their implementation was just what could be done, not what was desired. Seems u

Re: traits feedback

On Wed, Oct 5, 2011 at 8:44 PM, Brendan Eich wrote: > On Oct 5, 2011, at 8:21 PM, John J Barton wrote: > > I think what's missing is Object.extend: > > http://www.prototypejs.org/api/object/extend > http://api.jquery.com/jQuery.extend/ > http://dojotoolkit.org/reference-guide/dojo/extend.html > >

Re: traits feedback

On Oct 5, 2011, at 8:21 PM, John J Barton wrote: > I think what's missing is Object.extend: > > http://www.prototypejs.org/api/object/extend > http://api.jquery.com/jQuery.extend/ > http://dojotoolkit.org/reference-guide/dojo/extend.html > http://docs.sencha.com/ext-js/4-0/source/Object2.html#Ext

Re: traits feedback

On Wed, Oct 5, 2011 at 8:02 PM, Juan Ignacio Dopazo wrote: > On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten wrote: > >> Object.create does indeed require propertydescriptors as the second >> argument. This is the easiest way to send meta-data like read-only. >> >> However it's verbose and the de

Re: traits feedback

On 06/10/11 00:02, Juan Ignacio Dopazo wrote: On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten > wrote: Object.create does indeed require propertydescriptors as the second argument. This is the easiest way to send meta-data like read-only. However it's v

Re: traits feedback

On Wed, Oct 5, 2011 at 10:36 PM, Jake Verbaten wrote: > Object.create does indeed require propertydescriptors as the second > argument. This is the easiest way to send meta-data like read-only. > > However it's verbose and the defaults are restrictive. I've written a small > library (github.com/

Re: traits feedback

Object.create does indeed require propertydescriptors as the second argument. This is the easiest way to send meta-data like read-only. However it's verbose and the defaults are restrictive. I've written a small library (github.com/Raynos/pd) to make it less verbose, you might find it useful. On

Re: traits feedback

On Tue, Oct 4, 2011 at 8:56 PM, John J Barton wrote: > In trying to update my JS approach I looked into 'traits'. I'm still on the > fence about using them at this stage, but MarkM was asking for feedback of > pretty much any kind so here is a little. > > I believe I understand traits for the most

Re: traits feedback

On Wed, Oct 5, 2011 at 8:21 AM, Dean Landolt wrote: > > > On Wed, Oct 5, 2011 at 10:48 AM, John J Barton < > johnjbar...@johnjbarton.com> wrote: > >> >> >> On Wed, Oct 5, 2011 at 12:52 AM, Tom Van Cutsem wrote: >> >>> Thanks for the feedback, John. >>> >>> I have to admit that at first I was also

Re: traits feedback

On Wed, Oct 5, 2011 at 10:48 AM, John J Barton wrote: > > > On Wed, Oct 5, 2011 at 12:52 AM, Tom Van Cutsem wrote: > >> Thanks for the feedback, John. >> >> I have to admit that at first I was also taken aback by the apparent >> complexity of the "syntax for efficient traits" strawman. Traits have

Re: traits feedback

On Wed, Oct 5, 2011 at 12:52 AM, Tom Van Cutsem wrote: > Thanks for the feedback, John. > > I have to admit that at first I was also taken aback by the apparent > complexity of the "syntax for efficient traits" strawman. Traits have many > knobs, and require a lot of syntax to turn these knobs. >

Re: traits feedback

Thanks for the feedback, John. I have to admit that at first I was also taken aback by the apparent complexity of the "syntax for efficient traits" strawman. Traits have many knobs, and require a lot of syntax to turn these knobs. Regardless of whether you'd want nice declarative syntax for trait

traits feedback

In trying to update my JS approach I looked into 'traits'. I'm still on the fence about using them at this stage, but MarkM was asking for feedback of pretty much any kind so here is a little. I believe I understand traits for the most part just from the info on the Web site: http://traitsjs.org/