On Tue, Jun 9, 2009 at 12:37 PM, Christian Plesner Hansen<[email protected]> wrote: > > There is no technical reason for not storing templates in internal > fields. They're very similar to Externals in that regard: they're > safe to store in objects as long as they can only be accessed from > C++. > > The reason they're in a hierarchy of their own is that getting them > mixed up with ordinary values is in most cases dangerous and it seemed > safest to use the type system to separate them completely. The best > solution would probably be to allow internal object fields to hold > Handle<Data>s rather than Handle<Value>s since that is one case where > mixing the two is always safe.
I took a look at that, (also allowing callbacks' Data arguments to be Handle<Data>) but it could have a pretty high impact on the API. Luckily, I can get around it using pointer casts and explicit Handle creation. Handle<ObjectTemplate> template = ...; Handle<Value> hack(reinterpret_cast<Value*>(*template)); Thanks Matthias > On Mon, Jun 8, 2009 at 11:08 PM, Matthias Ernst<[email protected]> > wrote: >> >> So I've patched my local copy of v8 to support "Data" as internal >> object fields instead of "Value". >> It required changing all the v8::XX::Cast(Value *) methods to >> Cast(Data *) and adding an ObjectTemplate::Cast(Data *) like so: >> >>> ObjectTemplate* ObjectTemplate::Cast(v8::Data* that) { >>> if (IsDeadCheck("v8::ObjectTemplate::Cast()")) return 0; >>> i::Handle<i::Object> obj = Utils::OpenHandle(that); >>> ApiCheck(obj->IsObjectTemplateInfo(), >>> "v8::ObjectTemplate::Cast()", >>> "Could not convert to ObjectTemplate"); >>> return static_cast<ObjectTemplate*>(that); >>> } >> >> With that, building the structure outlined before seems to work fine. >> I'd still be interested to know whether this is kosher. >> >> Matthias >> >> On Mon, Jun 8, 2009 at 12:12 PM, Matthias Ernst<[email protected]> >> wrote: >>> Hi, >>> >>> Synopsis: I'm wondering how I can have a v8::Object point to a v8::Template. >>> >>> Here's what I'm doing: I'm hacking away at a protocol buffer wrapper. >>> >>> In my design, every protocol message type (represented by a >>> proto2::Descriptor*) is mapped to an ObjectTemplate. >>> Each property of the message type becomes an Accessor that calls back into >>> C++. The Accessor's "data" contains the proto2::FieldDescriptor and -in the >>> case of a sub-message- the object template used to wrap that submessage's >>> type. >>> >>> So for a message Outer { Inner inner; }, the layout I'd like to have is as >>> such: >>> ObjectTemplate"Outer" { >>> Accessor"inner" : { >>> Callback"read and wrap submessage", >>> Data: Handle->Object{ >>> External<FieldDescriptor"inner" *>, >>> Handle->ObjectTemplate"Inner" -> ... <= ******* >>> } >>> } >>> } >>> >>> I would like the whole structure to be managed by the V8 GC (the proto >>> descriptors are static data), i.e. I'd like the inner ObjectTemplates to be >>> GC'ed once I drop the outer one. >>> >>> However, and here's my actual problem, I cannot get the callback data to >>> refer to the inner v8::ObjectTemplate (*****), because the latter does not >>> extend v8::Value but only v8::Data. The only way I can imagine is using an >>> External wrapping a Persistent* but that would defeat the GC. >>> >>> So, is there a fundamental reason why "Data" cannot be used even as an >>> internal field of an Object? >>> I see that internally, in objects.h, an AccessorInfo's "Data" is not >>> required to be a JSObject but just an Object. >>> >>> Would horrible things happen if I coerced a Handle<ObjectTemplate> to be a >>> Handle<Value> and store it as internal fields of the callback Data? Could we >>> change Object::Set/GetInternalField to use Handle<Data>? >>> >>> Thx >>> Matthias >>> >>> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ v8-users mailing list [email protected] http://groups.google.com/group/v8-users -~----------~----~----~----~------~----~------~--~---
