Re: [whatwg/streams] Convert internal slot accesses in the reference implementation to use symbols (#443)

In my JS implementation I started with Symbols right from the beginning. The reason is that symbol properties do not end up in any serialization, such as JSON.

However, I think this choice is up to the implementors, and the spec shouldn't force this in any way, given that each platform has its own optimal way of defining and using internal properties.

Also, compliance shouldn't validate on internal properties, not even in tests. Deeper tests, that touch internal symbols should be kept per implementation.

My intention is to improve the performance of my JS implementation, and as such I might end up with re-ordering internal properties and algorithms.

As long as any implementation yields the same behavior, on the public methods and properties, I'd say there's greater benefit to allowing internals (properties and algos) up to the implementors. The goal is having a uniform set of interfaces and objects, that consumers can use regardless of the implementation.
Forcing this type of definitions on implementations might make it more difficult or sub-optimal for other implementations. E.g. using JS symbols in a C/C++ implementation is slower than using native un-exposed properties.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/443#issuecomment-225523278