I think (3) would be nice. There's also a bunch of code in api.cc and execution.cc that could be moved there.
On Fri, Sep 25, 2015 at 11:58 AM Jakob Kummerow <[email protected]> wrote: > As we have discussed at various occasions recently, we generally want to > move in the direction of having C++ implementations of spec-defined > behavior. That raises the question of where this code should live. > > As an example of the kind of code we're talking about, consider > https://codereview.chromium.org/1368753003/diff/1/src/runtime/runtime-object.cc > *(don't > panic, runtime-object.cc is not the intended final place for this code to > live -- the very purpose of this thread is to figure out a better place.)*, > but there are also other, existing examples (like various ToXXX conversion > functions, a bunch of things spread across runtime-*.cc, the JS > implementations littered with runtime calls that we want to replace, ...). > > Options I can think of: > > (1) Put everything into objects.cc. > + Makes a lot of sense for things like DefineOwnProperty_Array, which > could just be a static function JSArray::DefineOwnProperty. > + Is an easy approach in the sense of being consistent with existing code > structure (is that a good thing?) > − It's not clear how this approach maps to non-HeapObjects like the new > class PropertyDescriptor > − I like having some distinction between high-level spec-defined > operations like "DefineOwnProperty" and low-level V8 implementation details > like MigrateToMap -- installing both on the same class JSObject feels like > a recipe for confusion. > − objects.h/.cc are too big as it is, IMHO (of course this point is moot > if/when we split it up) > > (2) Put everything in runtime-*.cc > + Works, and there's plenty of precedent. > − AFAIK we have pretty wide consensus that that's not what we want. > − A concrete technical drawback is a lack of callability from other places. > > (3) Create a new directory, put everything there. > + All reference implementations would be in one place > + Can use individual files for further grouping if desired. Is that > desired? What file structure would be good? > + Personally I think we need more separation of things anyway, this is a > step in that direction > • next question: how to call that directory? src/spec/? src/es6/? > /src/blue/? (blue sheds are nice) > − For some things it might be unclear where to put them; our > "abstractions" are (necessarily?) leaky > − New thing to get used to; inconsistency while it's a work in progress > > (4) Organize by spec chapter, e.g. put OrdinaryDefineOwnProperty into > src/es2015/ch9/9.1.cc or somesuch > + If applied consistently, makes it easy to find things that are already > implemented, which avoids duplication > − the resulting grouping may or may not make sense (it's up to the spec) > − ugly > > Personally I'm leaning towards some variant of (3), but I'm open to being > convinced otherwise. (1) sounds like a temporary solution to me; why not go > for a longer-term plan right away? > > Thoughts? Other ideas? Indifference? > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
