Closed guybedford closed 1 year ago
Another option would be to have the JS binding mangle critical JS names like then
, toString
, and so on. I don't know what would be most idiomatic in JS for this, but perhaps something like a _
prefix since _
isn't otherwise used in component names, so you'd get _then
, _toString
, and so on in the bindings. In any case, that way we wouldn't have to worry about maintaining a union of all critical cases in all languages, which might need to grow over time. Would that work, and not be too ugly?
Yes, if we consider the scheme to be a comprehensive global renaming from a JS ecosystem perspective that might be ok. It could be a little surprising to have names just change, but it seems it could be mostly well-defined.
Doing renamings to avoid collisions as part of the language-specific bindings seems like the right way to go. Otherwise, it seems like we'd have to try to do a union of reserved words for a large set of languages that would ultimately be incomplete and also need to change over time.
Sure, will follow that approach in jco
.
Please point me to the right place if this has already been tracked somewhere, but I wanted to track keeping a list of specifically reserved function names on interfaces.
Specifically for JS, there are a number of functions which are implicitly called on objects:
then
- an interface with athen
function will never resolve in a promise return when passed through aPromise.resolve
function or returned from an async function.toString
- an interface with atoString()
method will have that method called when logging the interface in JavaScript, unclear if this is a good or bad thing, but something to be aware of. PossiblytoLocaleString()
as well.valueOf
- similarly totoString
, various algorithms call thevalueOf
function on objects.hasOwnProperty
,isPrototypeOf
,propertyIsEnumerable
- overrides the default intrinsic method on the JS object.It would be worth more clearly defining the criteria for reserving a name - should it be any behaviour changes, or only those changes which could be deemed "compatibility breaking".
Of the above,
then
is the one I'm most concerned about, since there would be no way to pass such interfaces around in async code in JavaScript.Other languages may have their own constraints too, it might make sense to maintain a union of these critical cases to avoid compat issues.