Re: Subclassing and private methods
Re: Subclassing and private methods
- Subject: Re: Subclassing and private methods
- From: Michelangelo Chasseur <email@hidden>
- Date: Wed, 07 May 2014 22:48:54 +0200
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 <email@hidden (mailto:email@hidden)> wrote:
>
> > On May 7, 2014, at 2:24 PM, Rick Aurbach <email@hidden (mailto:email@hidden)> 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 (email@hidden (mailto:email@hidden))
>
> 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:
>
> This email sent to email@hidden (mailto:email@hidden)
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden