> 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.
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,
(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
>
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
>> 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
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
> 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
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
>> 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
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
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
> 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 ?
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
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,
14 matches
Mail list logo