RE: Suggestion: Object.symbols

>> Well, a map is more often of dynamic size, mapping from one specific type T >> to another specific type U. (Of course, either can be variants.) An object >> is a bag of properties of fixed size, with keys of type string|symbol, >> values of a type specific to the property, metadata from the p

Re: Suggestion: Object.symbols

Well, a map is more often of dynamic size, mapping from one specific type T to another specific type U. (Of course, either can be variants.) An object is a bag of properties of fixed size, with keys of type string|symbol, values of a type specific to the property, metadata from the property descrip

RE: Suggestion: Object.symbols

> the consensus appears to be moving towards treating Objects like records But we have Map for this ? It’s difficult to follow the consensus... Why they “implemented” class if they don’t want classes, but “records” and no methods, but global/module functions ? Are we moving back to good old BASI

Re: Suggestion: Object.symbols

In my opinion, the consensus appears to be moving towards treating Objects like records, structurally typed bags of properties that don't change shape over their lifetime, and are thus statically analysable. See TypeScript's approach for a justification. On Thursday, 16 June 2016, doodad-js Admin

RE: Suggestion: Object.symbols

>> you'd have to present a use-case that's not better solved by "just use a Map" Simple... An object used like... an object ! An object with methods and attributes. https://www.npmjs.com/package/doodad-js ___ es-discuss mailing list es-discuss@mozilla.

Re: Suggestion: Object.symbols

Not in general, just for map-like usages, i.e. if you have an object where the keys are not static, you probably would be better served by a map. The problem with those functions you describe is that there are a large combinatorial set of them - did you want configurable, own, non-enumerable strin

Re: Suggestion: Object.symbols

On Wed, Jun 15, 2016 at 3:54 PM, doodad-js Admin wrote: >> I consider all of the 'get some arbitrary subset of properties from an >> object' use cases obsoleted by `Map`. But maybe I'm missing something >> obvious or not-so-obvious...? > > Objects, obsolete with Map ? “Map” is not meant to replace

RE: Suggestion: Object.symbols

> I consider all of the 'get some arbitrary subset of properties from an > object' use cases obsoleted by `Map`. But maybe I'm missing something obvious > or not-so-obvious...? Objects, obsolete with Map ? “Map” is not meant to replace objects, is it ? ___

Re: Suggestion: Object.symbols

Question is why would you actually want this when you have `Map`? I consider all of the 'get some arbitrary subset of properties from an object' use cases obsoleted by `Map`. But maybe I'm missing something obvious or not-so-obvious...? Cheers Alex On Wednesday, 15 June 2016, doodad-js Admin w

Suggestion: Object.symbols

Hi, There is "Object.keys" for enumerable-only own property names of an object, and "Object.getOwnPropertyNames" for enumerable and non-enumerable own property names of an object. Now we have "Object.getOwnPropertySymbols" which returns enumerable and non-enumerable own symbols of an object, bu

Re: A plan to help TC39 become more open up to community contributions and participations

> On Jun 15, 2016, at 2:12 PM, Bob Myers wrote: > > If you are referring to the standard ECMA-2 for a subset of ALGOL 60, this > was not a "standard for a programming language", but rather for a particular > ill-advised crippling of ALGOL, which not only removed `own` (sort of static) > varia

Re: A plan to help TC39 become more open up to community contributions and participations

If you are referring to the standard ECMA-2 for a subset of ALGOL 60, this was not a "standard for a programming language", but rather for a particular ill-advised crippling of ALGOL, which not only removed `own` (sort of static) variables, but much more importantly removed the key feature of recur

Re: A plan to help TC39 become more open up to community contributions and participations

Didn't know that. Nice to know! :-) On Wed, Jun 15, 2016, 11:48 Allen Wirfs-Brock wrote: > > On Jun 14, 2016, at 8:57 PM, Isiah Meadows wrote: > > Just an educated guess (I'm not actually involved in any part of this > effort - just a random person subscribed to this list), but I think it's > b

Re: A plan to help TC39 become more open up to community contributions and participations

> On Jun 14, 2016, at 8:57 PM, Isiah Meadows wrote: > > Just an educated guess (I'm not actually involved in any part of this effort > - just a random person subscribed to this list), but I think it's because of > ECMA itself. Granted, TC39 has already noted that this one doesn't exactly > fi

Re: A plan to help TC39 become more open up to community contributions and participations

> On Jun 6, 2016, at 3:21 AM, Salvador de la Puente González > wrote: > > Excuse my ignorance, but why do we need the legal organization, why to not > simply do the GiHub part? > https://en.wikipedia.org/wiki/Standards_organization may