another vote for (3). On Fri, Sep 25, 2015, 12:02 Jochen Eisinger <[email protected]> wrote:
> 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. > -- -- 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.
