RE: Suggestion: Object.symbols
> Symbols are enumerable by default just like normal properties. Object.assign > skips non-enumerable Symbols. Object.defineProperty can be used to create a > non-enumerable Symbol, but I believe that only impacts Object.assign (and > specific enumerability methods, obv). That’s exact. That’s not something critical, but “Object.symbols” looks like missing from the language. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Object.symbols
Symbols are enumerable by default just like normal properties. Object.assign skips non-enumerable Symbols. Object.defineProperty can be used to create a non-enumerable Symbol, but I believe that only impacts Object.assign (and specific enumerability methods, obv). On Thursday, June 16, 2016, doodad-js Admin wrote: > (quotes from G.Kay Lee) > > > > > I believe Symbols are all actually non-enumerable which will void the > suggestion. > > > > I can confirm they can be enumerable, or “Object.propertyIsEnumerable” is > lying to me. > > > > > And please, stop trying to add all kinds of trivial variations of > property extraction methods already. > > > > Who, me ? That’s not trivial We have “Object.keys” for enumerables, > why not “Object.symbols” for enumerables ? > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
FW: Suggestion: Object.symbols
(quotes from G.Kay Lee) > I believe Symbols are all actually non-enumerable which will void the > suggestion. I can confirm they can be enumerable, or “Object.propertyIsEnumerable” is lying to me. > And please, stop trying to add all kinds of trivial variations of property > extraction methods already. Who, me ? That’s not trivial We have “Object.keys” for enumerables, why not “Object.symbols” for enumerables ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Suggestion: Object.symbols
I believe Symbols are all actually non-enumerable which will void the suggestion. And please, stop trying to add all kinds of trivial variations of property extraction methods already. I also oppose the recently proposed Object.enumerableKeys and gang. On Thu, Jun 16, 2016 at 9:25 AM, doodad-js Admin wrote: > >> 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 descriptor, and a prototype chain. > > > > That’s exactly what I think of objects and Map. So back to > “Object.symbols” :) > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 >> descriptor, and a prototype chain. That’s exactly what I think of objects and Map. So back to “Object.symbols” :) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 descriptor, and a prototype chain. Nobody mention Array. ;) On Thursday, 16 June 2016, doodad-js Admin wrote: > > 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 BASIC > and COBOL languages ? > > > > Anyway, I have my polyfill for “Object.symbols”, I was just hoping for > something more performant. > > > > Thanks > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 BASIC and COBOL languages ? Anyway, I have my polyfill for “Object.symbols”, I was just hoping for something more performant. Thanks ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 wrote: > >> 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.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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.org https://mail.mozilla.org/listinfo/es-discuss
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 string-keyed properties? Map is both narrower in this sense (a map item is JUST a key and value with no metadata), and wider in its valid key types (no toString called!), which is more appropriate for many problems. Cheers Alex On Wednesday, 15 June 2016, 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 objects, is it ? > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 objects, is it ? It's meant to replace "objects used as maps". ^_^ That's one of the major reasons to use Object.keys(), so to justify adding a similar method for symbol-valued properties, you'd have to present a use-case that's not better solved by "just use a Map". ~TJ ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 ? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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 wrote: > 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, but > we are missing a function “Object.symbols” that returns enumerable-only own > symbols of an object. > > > > Thanks, > > > > Claude Petit > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
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, but we are missing a function "Object.symbols" that returns enumerable-only own symbols of an object. Thanks, Claude Petit ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
