ARC checks are probably pointless about inappstorewindow HOT 4 CLOSED

I think a static library is overkill for this project, I like the two file drop in model. It makes it really easy to add INAppStoreWindow to a project. Ease of use is the reason to have the arc detection throughout the file instead of requiring the user to add the per file compile flag, especially for new and novice programmers.

I think libraries should do as much as possible to be as simple and as easy to use as possible, even of that means making the code slightly ugly.

The code is done and the end user doesn't have to think about arc vs non-arc, I see no reason to change it.

David Keegan
davidkeegan.com

On Jan 14, 2012, at 2:02 AM, Jonathan [email protected] wrote:

So, files can be built with ARC specifically enabled or disabled for them, in spite of the main project's settings. Also, a static library can be used to segregate ARC from non-ARC code.

Given these things, it seems pointless to have all these checks whether ARC is available. If you want INAppStoreWindow to be able to be built for old systems on old tools, that's totally fine. People using INAppStoreWindow in ARC projects can simply jigger the build settings for those files, or package it in a static library. Thoughts?

---

Reply to this email directly or view it on GitHub:
#31

from inappstorewindow.

Thanks for your thoughts; I disagree, however. Incidentally, code is never “done”.

Whether a consumer is using ARC or not, whenever they add new code to their project, they do have to think about ARC vs. non-ARC. Since there is no expectation that all drop-in code will work under both modes, most users will end up opening up the source to INAppStoreWindow anyway to see what they need to do to make sure it builds correctly in their project.

In the end, it's really not that hard to add a few compiler flags to the the two files that are being imported into a project. You don't save the user much time or effort by cluttering up the code with preprocessor conditionals in ways that would likely baffle ARC's designers.

That said, if you still think that it's better this way, feel free to close this issue. That the ability to work seamlessly whether or not ARC is enabled is documented in your README is certainly a mitigating factor.

from inappstorewindow.

The decision to add arc/non-arc support within the file of INAppStoreWindow was made because when I download a library the first thing I want to do it use it, not search through the source for retains and releases. I don't care if a library is arc or non-arc, all I care about is the stability, performance, and API interface. This is why if at all possible I think it's a nice service to the end user to handle arc vs non-arc. I use a lot of submodules in my apps, some arc and some non-arc and it's bitten me a couple times where I forgot to add the compiler flags and there's an "oh yeah this is a non-arc library" moment. It's a minor annoyance but there are so many annoyances in programming that any of them that can be removed by a library author is a win in my book.

I think we are going to have to agree to disagree :)

from inappstorewindow.

Okeydoke.

from inappstorewindow.