On Mar 26, 2013, at 2:34 PM, Jarred Nicholls <jar...@webkit.org> wrote:
> On Tue, Mar 26, 2013 at 5:17 PM, Jesus Sanchez-Palencia <je...@webkit.org> > wrote: > 2013/3/26 Ryosuke Niwa <rn...@webkit.org>: > > On Tue, Mar 26, 2013 at 1:53 PM, Filip Pizlo <fpi...@apple.com> wrote: > >> > >> > >> On Mar 26, 2013, at 1:40 PM, Dirk Pranke <dpra...@chromium.org> wrote: > >> > >> On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain <benja...@webkit.org> > >> wrote: > >>> > >>> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke <dpra...@chromium.org> wrote > >>>> > >>>> If we have consensus that we should just switch to paths relative to > >>>> Source (or maybe a couple different options), that would be (IMO) a big > >>>> win. > >>>> It sounds like Daniel & co. have already done the big bang conversion. > >>> > >>> > >>> I think using full path would be a serious hit regarding hackability. > >>> > >>> I would rather spend some time tweaking my compiler to cache each > >>> directory content than waste time finding where is every single header I > >>> need to include. > >>> > >> > >> Interesting. I have the exact opposite experience, having to paw around to > >> figure out where "Font.h" actually lives rather than just seeing > >> "WebCore/platform/graphics/Font.h". > >> > >> At any rate, to be clear, I would be in favor of that change but I'm not > >> expecting it to happen :). > >> > >> > >> I'm with Dirk on this. Full path would help hackability for me. > >> > >> I don't use an IDE, so I'll be typing more. But I spend more time reading > >> code than typing code. > >> > >> Also we have a lot of stupid in header file naming right now. For example > >> the DFG calls the JSC::DFG::Node header "DFGNode.h", and puts it in > >> JavaScriptCore/dfg/DFGNode.h. So we duplicate the namespacing of > >> JSC::DFG::Node in both the filename and the directory name. Ridiculous! > >> If > >> we had a discipline to always include using paths relative to Source, then > >> we could just rename it to JavaScriptCore/dfg/Node.h. That would make me > >> happy. > > > > > > That'll make me sad because then Xcode will then find both > > WebCore/dom/Node.h and JavaScriptCode/dfg/Node.h when I type Node.h. > > > > Unfortunately, we can't name Node.h in WebCore/dom DOMNode.h because > > DOMNode.h already exists for Objective C bindings. > > > IMHO, we should be favoring code readability instead of a tool's feature. > > +1 for full paths. > > -jesus > > > My sentiment exactly. And I agree with Dirk and Filip, seeing full paths > improves (my) hackability and clearly shows layer dependencies (and > violations). I'd say that it would also help people understand where certain > headers live (educational) and to know which header specifically is being > included at compile time rather than it being a guessing game. This is just > my opinion, but its rendered through experience working in both chromium code > and webkit code. Having a few files named the same hasn't at all effected my > ability to find the right file (Sublime Text 2), though I understand that > argument. In fact I'm forced to learn the difference and distinguish the > locations between similarly named files in the code base; I've found it very > helpful. I realize that this is partly a matter of taste, and I do not feel too strongly. But I prefer being able to include headers by the short name without the include path. To me, listing the path feels like visual noise and doesn't aid my understanding. But I realize others may feel differently. I also dislike having files with the same name, whether or not you include them by full path. If you do that, then you need to disambiguate to even talk about a file. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
