Re: Forcing subclass creation through method swizzling not airtight?
Re: Forcing subclass creation through method swizzling not airtight?
- Subject: Re: Forcing subclass creation through method swizzling not airtight?
- From: Jean-Daniel Dupas <email@hidden>
- Date: Sun, 11 Mar 2012 16:25:58 +0100
Le 11 mars 2012 à 13:28, Antonio Nunes a écrit :
> On 11 Mar 2012, at 09:48, Jean-Daniel Dupas wrote:
>
>> +initialize is not call until you try to use your class.
>> So there is no garantee it will be call at all,
>
> Thanks Jean-Daniel,
>
> I think I can be pretty confident it is called, since this initialize is in my NSApplication subclass. Should be called before anything is done that involves PDF documents and pages.
>
> (By the way, now that I noticed the safeguard was missing, I adjusted the method to:
>
> + (void)initialize
> {
> if ( self == [NMD_Application class] ) {
> ...
> }
> }
>
>> and even if it is called, nothing prevent creation of instance of the super class before it append.
>
> Do you mean before the swizzling occurs? Knowing my code that would be unlikely. The only place where I don't control directly what type of page gets created is in the PDFThumbnailView when a user drags a PDF document in from the Finder, and that can only happen after the app has finished starting up and opened a document. But maybe you mean something else by "before it append"?
>
No. If you make sure the class is initialize before anything else append (especially before opening any document), and if the safe guard does not fix you issue, I don't see why it shouldn't work.
That said, I don't know either how PDFPage instances are created. It is perfectly valid for a PDFDocument to explicitly create subclass of PDFPage if it want to. In such case, your alloc method will never return a NMD_PDFPage instance.
I don't think it has anything to do with you issue, but in your replacement method, you can simply use (self == [PDFPage class]) instead of [self class], as you are in a class method, and self represent the class itself already.
-- Jean-Daniel
_______________________________________________
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