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. _______________________________________________ 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
