Thanks for the responses on what I recognize is a "nit pick" on an excellent library, despite my not using the mailing lists. :) I've moved the discussion there (I think).
The Handle<T> class works to manage interaction with the GC and that the String class is just C++ veneer to allow access to the underlying GC-managed JavaScript strings. However, there is a C++ class String with real C++ functions on it. And a Handle<String> is just a (smart) pointer to an instance of that class. The API actually guarantees that you can dereference a Handle<T> and use the pointed-to instance directly. The documentation of Handle<T> states: * It is safe to extract the object stored in the handle by * dereferencing the handle (for instance, to extract the Object* from * an Handle<Object>); the value will still be governed by a handle * behind the scenes and the same rules apply to these values as to * their handles. So, it is safe to pass a String*, because that's all that happens when you pass a Handle<String> (since it's just a smart, wrapped up String*), and the API documentation says you can. (Clearly, you still need some kind of Handle managing the pointer during all this.) If it is safe to pass String*, then it is safe to pass String&. They are the same thing: a "pointer" to the address of a C++ String instance. (After all, when you dereference a String*, you get a String&.) Using String* instead of String& doesn't do anything to guarantee that the pointed-to object still exists; it is the fact that the String is ultimately managed by a Handle<String> that takes care of that. For these reasons, I don't understand how using String* is any safer with regards to object lifetimes or interaction than String&, so I'm not sure why it wouldn't be okay for operator*() to return the conventional T* and thus offer the usual symmetry between p->f() and (*p).f(). -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
