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 v8-dev@googlegroups.com 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 v8-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
