NSNotificationCenter problem

  • Hi all,

    I have a very weird problem that causes me tearing my hair out. For the
    first time in my life something works beautifully well under GNUstep
    but not at all under MacOSX. And I have no idea why. I do

        [[NSNotificationCenter defaultCenter] addObserver:self
    selector:@selector(storeDidRevert:)
    name:SOInvalidatedAllObjectsInStoreNotification object:editingContext];

        [[NSNotificationCenter defaultCenter]
    postNotificationName:SOInvalidatedAllObjectsInStoreNotification
    object:editingContext];

    - (void)storeDidRevert:(NSNotification *)notification
    {
        NSLog(@"storeDidRevert...");
    }

    This works initially, but when I trigger

        [[NSNotificationCenter defaultCenter]
    postNotificationName:SOInvalidatedAllObjectsInStoreNotification
    object:editingContext];

    again, storeDidRevert: is not called anymore (only under MacOSX). My
    first guess was there must be an removeObserver: statement anywhere,
    but there is none. And I use exactly the same code on GNUstep where my
    code works perfectly! :-(

    Any idea how this can be tracked done efficiently (with gdb)? Under
    GNUstep I would raise an exception in removeObserver if
    notificationName is SOInvalidatedAllObjectsInStoreNotification but on
    MacOSX I cannot simply alter and recompile the code of
    NSNotificationCenter.

    Hints are greatly appreciated!

    Thanks,

      Andreas
  • On 1 Nov 2007, at 11:15 AM, Andreas Höschler wrote:

    > Hi all,
    >
    > I have a very weird problem that causes me tearing my hair out. For
    > the first time in my life something works beautifully well under
    > GNUstep but not at all under MacOSX. And I have no idea why. I do
    >
    > [[NSNotificationCenter defaultCenter] addObserver:self
    > selector:@selector(storeDidRevert:)
    > name:SOInvalidatedAllObjectsInStoreNotification
    > object:editingContext];
    >
    > [[NSNotificationCenter defaultCenter]
    > postNotificationName:SOInvalidatedAllObjectsInStoreNotification
    > object:editingContext];
    >
    > - (void)storeDidRevert:(NSNotification *)notification
    > {
    > NSLog(@"storeDidRevert...");
    > }
    >
    > This works initially, but when I trigger
    >
    > [[NSNotificationCenter defaultCenter]
    > postNotificationName:SOInvalidatedAllObjectsInStoreNotification
    > object:editingContext];
    >
    > again, storeDidRevert: is not called anymore (only under MacOSX).
    > My first guess was there must be an removeObserver: statement
    > anywhere, but there is none. And I use exactly the same code on
    > GNUstep where my code works perfectly! :-(
    >

    Are you also using the same (identical) editingContext object?

    > Any idea how this can be tracked done efficiently (with gdb)? Under
    > GNUstep I would raise an exception in removeObserver if
    > notificationName is SOInvalidatedAllObjectsInStoreNotification but
    > on MacOSX I cannot simply alter and recompile the code of
    > NSNotificationCenter.
    >
    > Hints are greatly appreciated!
    >
    > Thanks,
    >
    > Andreas

    You can always use a subclass and poseAsClass: for debugging. make
    sure you do it early enough (e.g. at the start of main()).

    Christiaan
  • On Nov 1, 2007, at 3:44 AM, Christiaan Hofman wrote:

    > You can always use a subclass and poseAsClass: for debugging. make
    > sure you do it early enough (e.g. at the start of main()).

    FWIW, this is deprecated in Leopard.

          - Scott
  • On 2 Nov 2007, at 2:28 AM, Scott Stevenson wrote:

    >
    > On Nov 1, 2007, at 3:44 AM, Christiaan Hofman wrote:
    >
    >> You can always use a subclass and poseAsClass: for debugging. make
    >> sure you do it early enough (e.g. at the start of main()).
    >
    > FWIW, this is deprecated in Leopard.
    >
    > - Scott
    >

    So what's the alternative in Leopard? There are situations where you
    don't have control over inserting subclasses, like this one.

    Christiaan
  • On Nov 2, 2007, at 2:59 AM, Christiaan Hofman wrote:

    > On 2 Nov 2007, at 2:28 AM, Scott Stevenson wrote:
    >
    >> On Nov 1, 2007, at 3:44 AM, Christiaan Hofman wrote:
    >>
    >>> You can always use a subclass and poseAsClass: for debugging. make
    >>> sure you do it early enough (e.g. at the start of main()).
    >>
    >> FWIW, this is deprecated in Leopard.
    >>
    >> - Scott
    >>
    >
    > So what's the alternative in Leopard? There are situations where you
    > don't have control over inserting subclasses, like this one.

    It looks like you can replace specific methods, like OBUtilities.
      http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ind
    ex.html


    --
    adam
  • On 2 Nov 2007, at 4:51 PM, Adam R. Maxwell wrote:

    > On Nov 2, 2007, at 2:59 AM, Christiaan Hofman wrote:
    >
    >> On 2 Nov 2007, at 2:28 AM, Scott Stevenson wrote:
    >>
    >>> On Nov 1, 2007, at 3:44 AM, Christiaan Hofman wrote:
    >>>
    >>>> You can always use a subclass and poseAsClass: for debugging.
    >>>> make sure you do it early enough (e.g. at the start of main()).
    >>>
    >>> FWIW, this is deprecated in Leopard.
    >>>
    >>> - Scott
    >>>
    >>
    >> So what's the alternative in Leopard? There are situations where
    >> you don't have control over inserting subclasses, like this one.
    >
    > It looks like you can replace specific methods, like OBUtilities.
    > http://developer.apple.com/documentation/Cocoa/Reference/
    > ObjCRuntimeRef/index.html
    >
    > --
    > adam

    I know. But it seems to me that if class posing is deprecated than
    method swizzling might also be "deprecated", perhaps even more so?

    Christiaan
  • On Nov 2, 2007, at 10:02 AM, Christiaan Hofman wrote:

    >
    > On 2 Nov 2007, at 4:51 PM, Adam R. Maxwell wrote:
    >
    >> On Nov 2, 2007, at 2:59 AM, Christiaan Hofman wrote:
    >>
    >>> On 2 Nov 2007, at 2:28 AM, Scott Stevenson wrote:
    >>>
    >>>> On Nov 1, 2007, at 3:44 AM, Christiaan Hofman wrote:
    >>>>
    >>>>> You can always use a subclass and poseAsClass: for debugging.
    >>>>> make sure you do it early enough (e.g. at the start of main()).
    >>>>
    >>>> FWIW, this is deprecated in Leopard.
    >>>>
    >>>> - Scott
    >>>>
    >>>
    >>> So what's the alternative in Leopard? There are situations where
    >>> you don't have control over inserting subclasses, like this one.
    >>
    >> It looks like you can replace specific methods, like OBUtilities.
    >> http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/ind
    ex.html

    >>
    >> --
    >> adam
    >
    > I know. But it seems to me that if class posing is deprecated than
    > method swizzling might also be "deprecated", perhaps even more so?

    From that page:

    class_poseAs: deprecated in favor of categories and
    method_setImplementation

    So there are now public, supported ways to replace IMPs.

    --
    adam
  • On Nov 2, 2007, at 10:02 AM, Christiaan Hofman wrote:

    > I know. But it seems to me that if class posing is deprecated than
    > method swizzling might also be "deprecated", perhaps even more so?

    Yes. Swizzling and all that hackery will not work in the future (64-
    bit, in particular) because the runtime is apparently moving away from
    making everything revolve around raw structs.

    The idea is to resolve the fragile base class issue. Along with better
    performance, better architecture, and so on.

        - Scott
  • On Nov 5, 2007, at 10:55 PM, Scott Stevenson wrote:
    > On Nov 2, 2007, at 10:02 AM, Christiaan Hofman wrote:
    >> I know. But it seems to me that if class posing is deprecated than
    >> method swizzling might also be "deprecated", perhaps even more so?
    >
    > Yes. Swizzling and all that hackery will not work in the future (64-
    > bit, in particular) because the runtime is apparently moving away
    > from making everything revolve around raw structs.
    >
    > The idea is to resolve the fragile base class issue. Along with
    > better performance, better architecture, and so on.

    You can still swizzle methods, you just can't do it in the raw Obj-C
    structures.  It is still considered naughty, but at least there is
    API via which you can commit the naughtiness in a somewhat predictable
    fashion (i.e. it'll do the right thing in terms of threading & cache
    flushing, but you'll still be hosed if you put the wrong IMP somewhere).

    Specifically:

    OBJC_EXPORT BOOL class_addMethod(Class cls, SEL name, IMP imp, const
    char *types);
    OBJC_EXPORT IMP class_replaceMethod(Class cls, SEL name, IMP imp,
    const char *types);

    And, yes, I don't like the "types" parameter any more than anyone
    else.  If you have suggestions as to how to make it more palatable,
    please file enhancement requests via (http://bugreporter.apple.com/).

    b.bum
  • On Nov 5, 2007, at 11:42 PM, Bill Bumgarner wrote:
    > You can still swizzle methods, you just can't do it in the raw Obj-C
    > structures.  It is still considered naughty, but at least there is
    > API via which you can commit the naughtiness in a somewhat
    > predictable fashion (i.e. it'll do the right thing in terms of
    > threading & cache flushing, but you'll still be hosed if you put the
    > wrong IMP somewhere).
    >
    > Specifically:
    >
    > OBJC_EXPORT BOOL class_addMethod(Class cls, SEL name, IMP imp,
    > const char *types);
    > OBJC_EXPORT IMP class_replaceMethod(Class cls, SEL name, IMP imp,
    > const char *types);

    Dang it.  Hit deliver too soon.  The whole point was also to say that
    these APIs are available in the 32 bit -- the legacy ObjC -- runtime,
    too.  You can write one bit of code that'll behave the same in 32 bit
    and 64 bit.

    Convenient and consistent, but it doesn't make it any more of a good
    idea to go and class_replaceMethod() on just any method of any class. ;)

    b.bum
  • On Nov 5, 2007, at 11:42 PM, Bill Bumgarner wrote:

    > You can still swizzle methods, you just can't do it in the raw Obj-C
    > structures.

    Ah. I think of swizzle as "isa swizzling," which implies mucking with -
    > isa.

        - Scott
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today