[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
From: Maciej Stachowiak <mjs () apple ! com>
Date: 2009-05-25 7:49:50
Message-ID: 64DC70A2-1CC5-4DD4-88B4-FA81206670F4 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On May 24, 2009, at 10:51 PM, Peter Kasting wrote:
> On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak <mjs@apple.com>
> wrote:
> I don't think it should be discounted. It might be helpful to
> clarify why you think ifdefs are a bad solution.
>
> Generally they make it more difficult to read the code (which is
> what I spend 99% of the time doing) without really making it easier
> to find what's in the build (which I only spend 1% of the time doing
> anyway). The reason for this latter is because there's a lot of
> files that look like they're included but I actually don't care
> about, while if you go the "#include foo_bar_gtk.cc" route to handle
> port-specific implementations, it can make it harder for your IDE to
> determine that foo_bar_gtk.cc is an important file (e.g. by doing
> "open foo_bar_gtk.cc" in its command line). (This depends on the
> IDE, of course.)
>
> I would prefer to optimize for reading the code for my port, which
> generally means as few #ifdefs as possible, and pushing as much
> logic into the build system as possible (by including or not
> including various files). It implies things like preferring per-
> port subclasses to port-specific members in the parent class,
> preferring to not include files rather than #ifdef their contents
> away... basically, the opposite of all the decisions WebKit looks to
> have taken :D
I'll agree that a bunch of #ifdefs in the middle of code can be hard
to read. In general though, I'm not sure that optimizing for only
thinking about one port is the right approach. Ideally, we should both
make it easy to work on only port-level stuff, *and* make it practical
for people doing core work with port-specific implications to do what
they need to do. I would even argue we should prioritize ease of core
work over ease of port-specific work, if we should ever face that
tradeoff.
>
> I don't think this is a big deal for most things, and I think the
> cases where it is a big deal have been dealt with well when they've
> come up in the past (from what I've seen as a third party -- usually
> Darin Fisher or someone else on the team is running into them), so
> don't take this as a disgruntled complaint against the current
> system. It's just my preference.
>
> Now, the thing I _would_ like to change is to switch from pathless
> #includes to ones with relative paths -- but that's a totally
> different thread.
That I definitely wouldn't like. It would make it much more painful to
move files. What is the benefit? Maybe UI am missing something.
Regards,
Maciej
[Attachment #5 (text/html)]
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><br><div><div>On May 24, 2009, at 10:51 PM, \
Peter Kasting wrote:</div><br class="Apple-interchange-newline"><blockquote \
type="cite"><div class="gmail_quote">On Sun, May 24, 2009 at 10:08 PM, Maciej \
Stachowiak <span dir="ltr"><<a \
href="mailto:mjs@apple.com">mjs@apple.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;"> <div style="word-wrap:break-word"><div>I don't think it \
should be discounted. It might be helpful to clarify why you think ifdefs are a bad \
solution.</div><div></div></div></blockquote><div><br></div><div>Generally they make \
it more difficult to read the code (which is what I spend 99% of the time doing) \
without really making it easier to find what's in the build (which I only spend 1% of \
the time doing anyway). The reason for this latter is because there's a lot of \
files that look like they're included but I actually don't care about, while if you \
go the "#include foo_bar_gtk.cc" route to handle port-specific implementations, it \
can make it harder for your IDE to determine that foo_bar_gtk.cc is an important file \
(e.g. by doing "open foo_bar_gtk.cc" in its command line). (This depends on the \
IDE, of course.)</div> <div><br></div><div>I would prefer to optimize for reading the \
code for my port, which generally means as few #ifdefs as possible, and pushing as \
much logic into the build system as possible (by including or not including various \
files). It implies things like preferring per-port subclasses to port-specific \
members in the parent class, preferring to not include files rather than #ifdef their \
contents away... basically, the opposite of all the decisions WebKit looks to have \
taken :D</div></div></blockquote><div><br></div><div>I'll agree that a bunch of \
#ifdefs in the middle of code can be hard to read. In general though, I'm not sure \
that optimizing for only thinking about one port is the right approach. Ideally, we \
should both make it easy to work on only port-level stuff, *and* make it practical \
for people doing core work with port-specific implications to do what they need to \
do. I would even argue we should prioritize ease of core work over ease of \
port-specific work, if we should ever face that tradeoff.</div><br><blockquote \
type="cite"><div class="gmail_quote"> <div><br></div><div>I don't think this is a big \
deal for most things, and I think the cases where it is a big deal have been dealt \
with well when they've come up in the past (from what I've seen as a third party -- \
usually Darin Fisher or someone else on the team is running into them), so don't take \
this as a disgruntled complaint against the current system. It's just my \
preference.</div> <div><br></div><div>Now, the thing I _would_ like to change is to \
switch from pathless #includes to ones with relative paths -- but that's a totally \
different thread.</div></div></blockquote><br></div><div>That I definitely wouldn't \
like. It would make it much more painful to move files. What is the benefit? Maybe UI \
am missing something.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div></body></html>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic