Fwd: method confusion

  • On Sep 17, 2007, Charles Steinman wrote:

    >
    > --- Hans van der Meer <hansm...> wrote:
    >
    >> In my code I have in a testcase:
    >> @interface HMCharacterAlphabetTest : SenTestCase {
    >> ...
    >> Inside one of the tests:
    >> HMCharacterAlphabet *alphabet =
    >> [[HMCharacterAlphabet alloc]
    >> initWithSize: 3];
    >> defined in class HMCharacterAlphabet as:
    >> - (id) initWithSize: (unsigned) size; // class in
    >> HMCharacterAlphabet.h
    >>
    >> Somehow arises confusion with the identically typed
    >> init in NSImage.h:
    >> - (id)initWithSize:(NSSize)aSize;
    >> [SNIP]
    >> I fail to see why this is possible, as these
    >> declarations are in
    >> different classes.
    >
    > But the compiler can't tell which class the method is
    > being sent to. The alloc method has a return type of
    > id, which could be anything. So when you send
    > initWithSize: to the result of alloc, the compiler
    > doesn't know what class it's talking to. I would

    Strange I thought at first, that redefining the init methods to return
    (HMCharacterAlphabet *) instead of id did not make the error go away.
    But if the return of the alloc as id is the culprit, then this makes
    sense of course and it confirms the above diagnosis.

    > change the method name to something that doesn't
    > conflict, but if you have to keep it the same, you can
    > statically type it as [(HMCharacterAlphabet
    > *)[HMCharacterAlphabet alloc] initWithSize: 3]. This
    > will give the compiler the information it needs to use
    > the right method signature.

    Indeed, this makes the error go away. But it is a solution I somehow
    find unattractive because in all object creations this cast will be
    needed.
    Renaming the method will be the most convenient I guess.
    Then cross my fingers Apple will not introduce that one too later on.
    Maybe I should resort to the solution of that problem given below.

    On Sep 17, 2007, Ricky Sharp wrote:

    (2) Suffix all ivars with _II (which then gave me unique accessors).
    For example:
    BOOL checked_II;
    -(void)setChecked_II:(BOOL)flag;

    Thanks to all people who did react to this question.

    Hans van der Meer
  • --- Hans van der Meer <hansm...> wrote:

    > Renaming the method will be the most convenient I
    > guess.
    > Then cross my fingers Apple will not introduce that
    > one too later on.

    In practice, this seems to be pretty unlikely for an
    initializer, especially if your name is reasonably
    descriptive. I've heard of a few method naming
    conflicts being introduced, but I've never heard of it
    happening to an initializer. (It may have happened and
    they just didn't feel a need to tell me, but I'm just
    saying, it doesn't seem to be all that common.)

    > Maybe I should resort to the solution of that
    > problem given below.
    >
    > On Sep 17, 2007, Ricky Sharp wrote:
    >
    > (2) Suffix all ivars with _II (which then gave me
    > unique accessors).
    > For example:
    > BOOL checked_II;
    > -(void)setChecked_II:(BOOL)flag;

    I don't mean this to insult Ricky, because he knows
    what's best for him and his software, but I wouldn't
    do this. For most people, I think attaching nonsense
    strings left and right will make the code less
    readable. I don't think mitigating this minor risk is
    worth reducing readability. If Apple does happen to
    introduce a conflict for the name (not very likely in
    the first place and less likely the more descriptive
    your name is), just find-and-replace it.

    Anyway, that's my take.

    Cheers,
    Chuck


    ____________________________________________________________________________________
    Need a vacation? Get great deals
    to amazing places on Yahoo! Travel.
    http://travel.yahoo.com/
previous month september 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