I would also consider forking the original project and modifying the pod. Then you would be able to include the pod in you Podfile by just specifying the URL of the forked git repo.
Just my 2 cents. Mike -- Michelangelo Chasseur Il giorno mercoledì 7 maggio 2014, alle ore 21:38, Rick Aurbach ha scritto: > On May 7, 2014, at 2:33 PM, Charles Srstka <cocoa...@charlessoft.com > (mailto:cocoa...@charlessoft.com)> wrote: > > > On May 7, 2014, at 2:24 PM, Rick Aurbach <r...@aurbach.com > > (mailto:r...@aurbach.com)> wrote: > > > > > I am using a CocoaPod that ALMOST does what I want it to. It appears that > > > I can get the desired behaviors by subclassing it (creating a category is > > > also a possibility, although doing so has the same problems as > > > subclassing). > > > > > > Obviously, I would like to create as minimal a subclass as possible (and > > > avoiding duplicating existing code), but doing so requires access to > > > private methods of the original object. The problem is that I need to use > > > methods which are not declared outside of the @implementation section of > > > the class and a property which is ONLY declared in the class’s anonymous > > > category interface (i.e., @interface theClass () … @end).. > > > > > > Now I understand that trying to gain access to private methods is > > > generally a BAD IDEA, since almost any change to the original CocoaPod > > > could break my class. And I may (i.e., probably will) resolve the issue > > > by duplicating otherwise unnecessary code in my subclass. But before I do > > > so, I’d like to survey what people think, how they approach this problem, > > > etc. > > > > > > (This is sort of like the undefined selector issue that has been > > > discussed recently, but seems to me to be a slightly different wrinkle.) > > > > > > What do you do?? > > > > Is the superclass your code? If it is, just move the class extension (i.e. > > @interface MyClass () ... @end) to a separate file named MyClassPrivate.h, > > add declarations for any private methods the subclass needs to call, and > > have the subclass import that. > > > > If the superclass is not your code, then it's best to find a way to do what > > you need without calling the private methods. > > Thank you Charles. I agree with both of your thoughts. (I.e., I had > considered the private interface file and your second point is exactly why I > pointed out that it was probably a bad idea… > > You help confirm my own thinking on this. > > Cheers, > > Rick Aurbach > Aurbach & Associates, Inc. > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com > (mailto:Cocoa-dev@lists.apple.com)) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > (http://lists.apple.com) > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/chasseurmic%40gmail.com > > This email sent to chasseur...@gmail.com (mailto:chasseur...@gmail.com) _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
