Some quick thoughts. Option (4) is a non-starter. Section numbers are not stable across spec releases.
Option (3) doesn't sound bad, although it's not quite clear what the criteria for putting something into objects vs runtime vs the new dir would be. If we introduced a third category, not only stuff from runtime but also significant parts of the logic in objects.cc should naturally move there. Sounds like a lot of work with unclear benefit. Option (1) seems like the most adequate for now. IMHO, thinking about a new directory structure is putting the cart before the horse at this point. It only is interesting as part of a broader strategy for splitting up objects.h/cc. I don't think we currently have any plausible plan for that. /Andreas On 25 September 2015 at 11:58, Jakob Kummerow <jkumme...@chromium.org> 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 > 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. > -- -- 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.
