One important bit tho: The (static) methods should be somewhere close the classes they relate to, otherwise we just go back to runtime-*.cc.
On Fri, Sep 25, 2015 at 1:37 PM, Benedikt Meurer <bmeu...@chromium.org> wrote: > AFAIK everyone is doing (1) currently, and so at least for now, which is > kinda what we agreed on some time ago. I don't see why we have to change > that now. I think (3) is essentially (2) with a different directory/base > filename, and many people thought that (2) was bad, which AFAIR is why we > are at (1) currently. I'm fine with moving objects.cc/.h somewhere else > and/or split them up, but I think we should delay that for now. This will > just be distracting for the work that has to happen in that area IMHO. > > On Fri, Sep 25, 2015 at 12:39 PM, 'Andreas Rossberg' via v8-dev < > v8-dev@googlegroups.com> wrote: > >> 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. >> > > -- -- 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.
