I am building a project that I might consider to open source. I have a UIView Category that gives me easy accessors for setting x,y coordinates, or width and left directly to a UIView, without dealing with the frame. My question is, should I use such categories in my project if I plan to open source it?
A lot of projects will have a similar category with methods for UIView like
- (void)setLeft:(CGFloat)left;
or
- (void)setX:(CGFloat)x;
And my understand is that if 2 categories create a method, you will have no guarantee about which is going to be called.
So... what should I do? Not use category at all and deal with this annoying code in my open sourced project? Use categories and maybe prefix the method names?
Thank you!
To say it even more briefly, such software must include source code and allow distribution (even under the same name and license of an initial product) in the form of a source code as well as in compiled form. A program can be modified and used in derived works by anyone regardless of industry or project.
Users of closed source software are prohibited from modifying or editing the application's source code. In fact, doing so can void the software's warranty and, in some cases, even result in legal consequences.
Responding to issues, reviewing code, and evangelizing your project are all important tasks in an open source project. While the amount of time you spend on non-coding tasks will depend on the size and scope of your project, you should be prepared as a maintainer to address them yourself or find someone to help you.
Yes, it is possible to make an open source project into a closed source project. The copyright holder can change the license of a project at any time, or cease to distribute source code of new releases. New releases can therefore be made closed source.
Don't bother adding these methods.
They save very little typing, the prefix you really should add will be ugly, and they add almost no real convenience while making code written against that added API no longer portable to projects that lack it.
As well, having a bunch of convenience methods makes it significantly more difficult to subclass. Which method(s) do you have to override? What is the behavior of KVO? Is there a primitive method that everything is funneled through or do you really have to override everything?
The frameworks generally do not add such convenience API because it creates a lot of extra "weight" to the API while incurring all of the issues mentioned above. All those extra methods are just more data points for the developer to have to learn about, remember, and explain to others when introducing new people to the project.
One exception is the class cluster classes; NSString, NSArray, etc... they have a core set of primitive methods that provide all functionality needed to implement the rest of the APIs. The rest of the methods on the abstract classes are implemented entirely in terms of those primitive methods. When subclassing, you only need to implement the primitives and all other behaviors will "just work". However, subclasses are free to override any of the non-primitives for optimization or customization purposes (though, careful, you really should preserve the behavior).
The general rule of thumb is that if a convenience API doesn't save more than a few lines of code on a regular basis, it isn't worth it.
Since Objective C doesn't support namespaces a common way to make sure your code is unique if you're planning to share it is to prefix your methods with a few letters that relate specifically to your project.
If you rename setLeft and setX to be called LMSetLeft and LMSetX you should reduce the chance of collisions significantly.
This should also be a really easy change as long as you use your IDE's refactor tool.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With