> On 2 Oct 2015, at 12:40, Quincey Morris <quinceymor...@rivergatesoftware.com> > wrote: > > On Oct 1, 2015, at 22:18 , Graham Cox <graham....@bigpond.com> wrote: >> >> It’s not really about making the compiler happy, it’s about making your code >> clear and bug-free. > >> The compiler is telling you your design is probably faulty, but the correct >> solution depends on your true intentions. What are they? You’ve slightly >> obfuscated the problem using pseudocode, so there’s no way to tell what’s >> the correct solution unless more info is provided. > > I agree with what you say, but there is a bigger pitfall to avoid. If the > subclass provides a second implementation of ‘stuff’, then it also provides a > second ‘stuff’ instance variable. That probably causes BaseThing to break > horribly — if it ever refers to its own instance variable directly. Is that > likely to happen? Of course. Recommended practice is for a class to refer to > the instance variable in its init methods, instead of using the corresponding > property. > > If the intention is merely to change the ‘stuff’ return type in the subclass, > then @dynamic is the correct way to go. If the intention is to have two > property implementations, then the subclass ‘stuff’ should be called > something else.
I guess the inherited code just wants to change the ‘stuff’ return type in the subclass. So I added @dynamic to the subclass, and all seems to be ok. Thanks for clearing this up. Kind regards, Gerriet. _______________________________________________ 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
