+1, FWIW. Templates as implementation detail should be abstracted using
typedefs. Even templates as API can use typedef shorthanding -- it's a
form of B&D programming to make all consumers spell out the long-hand
just to be over-concrete, or pay homage to C++.
/be
Bobby Holley wrote:
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
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
