We are thinking in the similar direction. But we would like to combine check and T* value extraction in a single operation. When I last talked to Erik and Kevin we decided to use something along the lines of
T* var; if (!result->AsObject(&var)) return result; This variation of poor man's pattern matching gives us static guarantee instead of dynamic check. -- Vyacheslav Egorov On Fri, Oct 1, 2010 at 7:03 PM, Vitaly Repeshko <[email protected]> wrote: > Here's my take on this problem: http://codereview.chromium.org/3558004/show > > There's a new FailureOr<T> template > (http://codereview.chromium.org/3558004/diff/1/8) that is supposed to > be used in allocation functions like this: > > FailureOr<JSObject> AllocateJSObject(Map* map); > > and in consumer functions like this: > > FailureOr<JSObject> object = AllocateJSObject(map); > if (object.is_failure()) return object; // check and propagate. > object->SetProperty(...); // operator-> requires a prior is_failure > check in debug mode. > FooBar(object.get()); // get() returns the object (also requires the check). > // ~FailureOr<T> requires that the object was either checked or copied. > > In the patch linked above I only converted a few functions (it > compiles and passes the tests). Until we have everything switched to > FailureOr there are a few public helper methods adding unnecessary > ugliness. I too agree that we should eventually get rid of automatic > Failure to Object upcasting. These two types should only meet in > really low-level places like the C++/JS boundary. > > What do you guys think? > > > Thanks, > Vitaly > > On Thu, Sep 30, 2010 at 3:00 PM, Kevin Millikin <[email protected]> wrote: >> Just thinking out loud: instead of a base class that both Failure and Object >> (couldn't it be HeapObject?) extend, you could use two separate channels. >> Change all the allocation functions to take a HeapObject** and return a >> error code. >> Instead of: >> MUST_USE_RESULT static Object* CreateJSValue(JSFunction* constructor, >> Object* value) { >> Object* result; >> ALLOC_CHECK(result =, Heap::AllocateJSObject(constructor)); >> JSValue::cast(result)->set_value(value); >> return result; >> } >> You could have some variant of: >> MUST_USE_RESULT static ErrorCode CreateJSValue(JSFunction* constructor, >> Object* value, >> HeapObject** result) { >> ErrorCode code; >> if (!(code = Heap::AllocateJSObject(constructor, result))) { >> return code; >> } >> JSValue::cast(result)->set_value(value); >> return ErrorCode::Success(); >> } >> It avoids the nasty macro that takes half an assignment expression as >> argument. >> On Thu, Sep 30, 2010 at 3:39 AM, Erik Corry <[email protected]> wrote: >>> >>> http://codereview.chromium.org/3522008 >>> >>> This is an experiment. The edits to objects.cc are done with an >>> automated tool and are intended as an illustration. They probably >>> don't compile. Would this be a win and can anyone think of a neater >>> way to do it? >>> >>> -- >>> Erik Corry, Software Engineer >>> Google Denmark ApS - Frederiksborggade 20B, 1 sal, >>> 1360 København K - Denmark - CVR nr. 28 86 69 84 >>> >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >> >> -- >> v8-dev mailing list >> [email protected] >> http://groups.google.com/group/v8-dev > > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
