Then the question becomes whether in this case the templates are an
implementation detail or a useful part of the type. bz has code that
makes use of the fact that they're templates. It sounds like our marking
code does something similar. Both of those imply that it is an aspect of
the types that is relevant to users, not just an implementation detail.
I suppose you could argue that you could use both, typedefs by default
and templates only when you need them. But having both means people
always have to decide which to use, which feels to me like unnecessary
API friction.
On 06/20/2013 11:12 AM, Brendan Eich wrote:
+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.
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
