I like the typedefs myself. But more fundamentally, I believe pretty strongly that we should do the same thing in and outside of the JS engine (so that, in particular, JS hackers are eating their own dogfood). I've mandated this by fiat in XPConnect, but also believe that the current mandate of "typedefs in the engine, templates in the browser" is undesirable.
Using the templates in the browser is particularly crappy because browser code generally doesn't |using namespace JS|. So you end up having to namespace-qualify twice: JS::MutableHandle<JS::Value> bholley On Thu, Jun 20, 2013 at 7:21 AM, Till Schneidereit <[email protected]>wrote: > All! > > We still don't have a clear line on how to name handles, both in- and > outside of the engine. Or, if we do, it's pretty unevenly distributed. > > Seeing as how everyone in the world just loves a good discussion about > naming (and how we should probably get to something resembling consistency > before handles are used outside the engine too much), let's get this thing > going, shall we? > > Here's my opening gambit, in IRC-based collaboration with @ted and @jonco, > and opposition from @evilpie: > > Options: > 1. don't use any typedefs at all, so always use (js:: and JS::)Handle<Foo*> > 2. change the template to the form Handle<Foo>, roughly matching what v8 > does > 3. use typedefs everywhere, so always use HandleFoo > > Personally, I favor the last of these options, because: > 1. it is the cleanest, least cluttery one > 2. v8 seems to get by just fine with option 2, somewhat countering the > argument for option 1 that everything else hides the fact that you're > dealing with heap values > 3. Handle<T> isn't a general container people can use with their own Ts, so > the fact that it's a template in the first place is an implementation > detail that shouldn't be exposed > 3. it scales linearly with the number of JSObject subclasses, so isn't > really going to be a burden going forward > > That's all I've got, I think. > > > till > _______________________________________________ > dev-tech-js-engine-internals mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
