On Fri, May 5, 2017 at 6:02 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: > I'm not sure this is going to work in this case. WebIDL interfaces that > don't require refcounting basically require that the JS object owns the C++ > thing; it will delete it when finalized. > > You could do non-virtual no-op refcounting. But you still have a problem > where ToJSValue only knows how to work with subclasses of either nsISupports > or nsWrapperCache, both of which involve virtual functions.
Yeah, that's not OK for my case. > If I can take a step back, though, you have the following requirements: > > 1) The same Encoding* has to lead to the same JS object. I thought that == could be true when the objects aren't the same as with strings, but now that I look at the spec, it seems that I was wrong. But perhaps chrome JS could get away with not comparing these things: just passing them from one XPCOM API to another. > 2) The JS representation needs to be an object. This is probably good in > terms of typesafety (in that we can check whether the object is actually the > thing we were passed), but complicates the other bits. For example, if this > were not a requirement, we could conceivably use a JS PrivateValue to just > directly encode the Encoding* in a value that looks like a JS Number. This > does mean that on JS-to-C++ conversion we'd effectively reinterpret_cast a > double to an Encoding*, so if someone messed up and passed some random > double bad things would happen. I suppose compared to that it would be pretty tame to have a string-based API that MOZ_CRASHes if the string argument isn't an encoding name. (Previously, we couldn't do that, since XPCOM extension bugs could then crash the browser, but maybe we could have higher expectations for our own chrome JS.) > One thing that is not clear to me: do you need support for this on worker > threads, or just mainthread? I'm not sure what chrome JS runs on non-main threads and if there's non-main-thread chrome JS doing things like obtain an encoding name from a channel and pass it to the UTF8 converter service. > This would be a bit of work, but not too insane, I think. This seems complicated enough that it's probably the best to have non-scriptable methods that are type-safe for C++ usage and scriptable overloads that deal with encoding names as strings for chrome JS. After all, Web Platform JS represents encodings as strings, too. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
