-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make devices and presences lack property names #793
Conversation
Ugh, Looks like it's in SwingSet, in |
6c1bbb7
to
c5b033f
Compare
Even if they are marshalled as presences, a presence should have no property names or symbols. Still allow identification by setting a prototype with a toString() method and a [Symbol.for('SwingSet')] property.
c5b033f
to
8700aba
Compare
I've updated the approach: the current idea is to represent presences as an empty object with a prototype that defines: {
toString() { ... },
[Symbol.for('SwingSet')]: true,
[Symbol.toStringTag]: description,
} This allows for simple identification of the objects in the REPL, as well as informative printing and stringification. |
For example:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7479b91
to
ad662c8
Compare
Is this subsumed by #804 ? |
Yes. |
Closes #792
This PR improves the debuggability and predictability of device nodes and presences created by SwingSet and CapTP. Adding a
Symbol.for('SwingSet')
property (which doesn't show up withObject.getOwnPropertyNames
), and setting a prototype that definestoString()
(which allows the presence to be stringified as before) means that empty objects are marshalled compatibly as empty presences.The REPL is improved to sniff specifically for this mechanism to distinguish presences from empty objects.