Object properties indexed by symbols

[gautaz]

Hello,

Currently all Object methods consider that an Object property can always be accessed through its name as a String.
ES6 has introduced symbols and the need to access a property through a Symbol can occur sometimes.
So I was wondering what will be the preferred Sanctuary way to handle this use case.

[davidchambers]

You may have noticed several ways in which Sanctuary does not accommodate new language features. This reflects my view that the majority of new language features are unnecessary and primarily serve to increase the complexity of the language. Examples:

• default parameters have been problematic for decades (['10', '10', '10'].map(parseInt));
• class indirectly promotes the use of mutable objects;
• async and await are more complex than an abstraction such as Future;
• promises are more complex than the callbacks they replace; and
• public symbols seem to undermine the reason for adding symbols to the language.

Ecma-262 Edition 5.1 is and will remain the best version of the language, from my perspective. The majority of language features added since June 2011 address problems which would have been better addressed by libraries.

Now to your question about using symbols. I don't think Sanctuary will ever provide a function which deals with symbols explicitly (though polymorphic functions such as S.I should accept symbols). Would it be possible to briefly step outside the sanctuary in order to interact with the “foreign” code? Replacing S.prop (symbol) with record => record[symbol], perhaps?

[gautaz]

Would it be possible to briefly step outside the sanctuary in order to interact with the “foreign” code? Replacing S.prop (symbol) with record => record[symbol], perhaps?

Yes ! In fact that was how I dealt with it :-).

I have also mixed feelings about the new language features so I understand your point of view on this matter and mostly agree with it.
I am just wondering if this position is sustainable for Sanctuary on the long term because new "alien" language features might interfere more and more.

I am closing the issue for now but feel free to reopen it if needed.

[davidchambers]

I am just wondering if this position is sustainable for Sanctuary on the long term because new "alien" language features might interfere more and more.

We will see. I believe the broader JavaScript community will eventually realize that it is the continually increasing complexity of the language which is unsustainable. ;)

[tomkel]

public symbols seem to undermine the reason for adding symbols to the language.

Can you expand on this point a little David?
I think that there may be a place for Symbols in Sanctuary, such as replacing all of the @@ or fantasy-land/ keys, which are namespaced to avoid collisions. That is exactly the problem that Symbols solve.

[gabejohnson]

@tomkel prefixed methods using strings is in the Fantasy Land spec. sanctuary-type-classes wouldn't be spec-compliant if it used symbols instead.

[davidchambers]

As I understand it, symbols were intended to give implementors a way to attach properties to an object which are guaranteed not to collide with properties added by third parties. I could write

object[symbol] = "can't touch this";

and be sure that even if I give you object you won't be able to access or override the value I set, because I hold the key (the symbol I created). If I give you the key, though, all bets are off.

I think that there may be a place for Symbols in Sanctuary, such as replacing all of the @@ or fantasy-land/ keys, which are namespaced to avoid collisions.

Authors of algebraic data type libraries need access to the various strings or symbols (currently these values are strings such as 'fantasy-land/map'). The fantasy-land package could export symbols instead, but there are several problems with doing so, as @robotlolita outlined in fantasyland/fantasy-land#92 (comment).

[paldepind]

@davidchambers

I don't think you're being entirely fair to modern ECMAScript. There is a lot of good stuff in there 😄

The majority of language features added since June 2011 address problems which would have been better addressed by libraries.

Which features? I can think of very few new features that could have been better addressed by libraries. Stuff like generators, const, Object.freeze, =>, Set/Map, destructuring and import are all things that cannot be implemented in libraries.

I can only speak for my self but I've gotten so used to the new features that writing in ES5 feels like a significant step-down. I now get nervous when I see a var 😰 . Maybe it would be worth it to consider adopting ES6 "The good parts"?

[davidchambers]

I'm a Lisper at heart, Simon: highlighted words in my text editor feel like errors. ;)

Maybe it would be worth it to consider adopting ES6 "The good parts"?

We should certainly consider this. We could decide which feature is most important to us, consult the MDN compatibility table, then poll Sanctuary users to determine the proportion of users who would be negatively affected were we to use the feature.

[tomkel]

Thanks for pointing me to that post David. I agree that the benefits of moving to symbols (cleaner, less chance of collision) are not worth forcing the whole community to migrate. I just want to point out that cross-realm symbols are possible with Symbol.for, yet they are keyed with strings, so that brings the problem full circle.

[davidchambers]

I just want to point out that cross-realm symbols are possible with Symbol.for, yet they are keyed with strings, so that brings the problem full circle.

Well put. 🤣