On Sun, Mar 22, 2009 at 18:43, Christian Plesner Hansen
<[email protected]> wrote:
>
> Ivan,
> The way this is expressed in the api it effectively removes the
> distinction between externals and integers, which I would say is a Bad
> Thing(TM).  As the code is now it no longer holds that
> External::Cast(x) succeeds iff x->IsExternal().  This may just be an
> oversight but if we change IsExternal to match Cast then
> Number::New(1.0)->IsExternal() will yield true, as will
> External::New(0)->IsInt32().
>
> We don't have this blurring of types anywhere else in the api and,
> depending on what the motivation was for adding this, I think we
> should look for a different way of expressing this that avoids it.  We
> might for instance add static member functions for wrapping and
> unwrapping pointers that work directly with Values, where we can
> document that you shouldn't depend on the exact type of value
> produced.
>
> What do you think?

As I said in a private chat to Christion I think the suggestion to
have statics convert from pointers to values and back without any
guarantees about the type of the values is probably the best way to go
about this. I will take a look at it on Monday.

-Ivan


>
>
> -- Christian
>
> On Sat, Mar 21, 2009 at 8:39 AM,  <[email protected]> wrote:
>>
>> LGTM
>>
>> I think we might be doing this manually in the chromium binding layer.
>> With this change, we should be able to simplify that.
>>
>> http://codereview.chromium.org/42466
>>
>> >
>>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to