[cfe-commits] [PATCH] Add -fobjc-direct-class-refs

[Douglas Gregor]

On Jun 5, 2012, at 6:46 AM, Jonathan Schleifer <js at webkeks.org> wrote:

> Am 19.05.2012 um 21:34 schrieb John McCall:
> 
>> I apologize that this means significantly more work for you;  it's always
>> awkward being the one forcing a generalization.
> 
> I'm not really deep enough into Clang to rewrite the whole way how clang handles different runtimes and I actually think that asking me to rewrite all that when I just wanted a single flag is a little bit too much, don't you think? This is the first Clang patch that's more than a 1-liner I ever did and it took me ages to get the options stuff working. Someone who actually is familiar with the Clang code should be able to do this much faster with less work.
> 
> Can't you just let me have this one single option and then later someone who is familiar enough with Clang can rewrite the way Clang handles different runtimes?

Agreeing to what you are asking for would be a terrible policy decision for the project. When the special cases add up, we have to generalize or the code base becomes unmaintainable. If you peruse the commit logs, you'll see this happening everywhere: developers generalize and refactor to make something beautiful, then slide their new feature into that framework. It's how the LLVM/Clang community continually improves the code base, and it is the reason that we're able to build as much as we have so quickly. 

Remember, adding a command-line option extends the user interface of Clang. We can't just take that command-line option back once we've added it. So, let's imagine that we take this one single option. Then, down the road, someone does the necessary generalization, and we have a new command-line option. Unfortunately, the old command-line option can never go away, because people depend on it, so we have to map old to new "forever". Now multiply this by everyone who wants just one single option/feature/etc., and you have a horrible mess down the road.

We're all reaping the benefits of us *not* allowing little exceptions like this in Clang. Let's keep doing things the right way when we know what that is.

	- Doug