Chromium's bindings layer uses External to associate opaque data with V8 objects and callbacks (see methods accepting Handle<Value> data in V8 api).
So making External into a non-Value might involve some bindings work. -- Vyacheslav Egorov On Fri, Sep 7, 2012 at 2:50 PM, Sven Panne <[email protected]> wrote: > After several discussions, it is not so clear anymore what to do. First of > all, SilkJS does not follow https://developers.google.com/v8/embed#dynamic > on how to handle foreign (i.e. C/C++) pointers when embedding v8. The return > value of External::New is supposed to live in an internal field, but it is > *not* a valid JavaScript value, it is just a Foreign in disguise, sometimes > optimized to a Smi. Our v8.h header is very confusing regarding this fact, > and having External as a subclass of Value is basically wrong. Furthermore > Value::IsExternal is completely broken. I can see 2 ways of fixing things: > > * Keep External's implementation basically as it is. i.e. either a Smi or > a Foreign. If we do this, we should not keep External as a subclass of Value > (perhaps a subclass of Data?) and we should remove the IsExternal predicate. > This means that e.g. SilkJS has to change, following > https://developers.google.com/v8/embed#dynamic. As it is, one can easily > crash SilkJS by pure JavaScript. > > * Make External basically a convenience wrapper for a JavaScript object > with an internal property containing a Foreign. This way we could keep > External a subclass of value and we could fix IsExternal. The downside is > that all code already following > https://developers.google.com/v8/embed#dynamic would basically do a useless > double indirection, punishing people following that guide. > > We will discuss these options, there are good arguments for both of them... > > Cheers, > S. > > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
