Re: How to override properties
Re: How to override properties
- Subject: Re: How to override properties
- From: Graham Cox <email@hidden>
- Date: Fri, 02 Oct 2015 15:18:48 +1000
> On 2 Oct 2015, at 2:28 pm, Gerriet M. Denkmann <email@hidden> wrote:
>
> don’t think that I want ’stuff’ to be implemented by its superclass.
Are you sure? The only thing the subclass has changed about the property is its type, which is in itself a subclass of the original type, so it should be possible to substitute either class for “stuff”. I would expect the base class to implement it.
> Rather I want it to be overridden. So I am not sure, whether @dynamic is the right thing to do.
>
> How to make the compiler happy?
It’s not really about making the compiler happy, it’s about making your code clear and bug-free.
It might be convenient to return stuff as a different class in the subclass, but then you’re subverting the substitution principle. It would probably be better to have a different property in the subclass, such as ‘stuffAsSubDataClass’ which internally calls the original stuff property, perhaps converting or type checking as needed. If either property is observable you can make one trigger observations on the other and vice versa as necessary using the class methods +keyPathsForValuesAffecting<property>.
If it’s illegal for the property ‘stuff’ to be the subclass (or base class) type when hosted by your subclass original base or original base clas respectively (as decided by your design), then you probably want to make it a totally unrelated property, since presumably it would be a bug to pass an instance of ‘someDataClass’ to -[SubThing stuff], because then [SubThing stuffAsSubDataClass] (or [SubThing stuff] forced to have a different return type) could not fulfil its contract (unless it performs a conversion).
In other words: if SomeDataClass/SubDataClass is substitutable, then the base class should implement ‘stuff'. If not, then they should be independent separate properties. It seems like you’re trying to make it a kind of union, where the same storage is used for two different types of things. There isn’t a way to express that, and there’s no benefit to it even if you could.
If every subclass of SomeDataClass has a different type returned by ‘stuff’ then you might be better off making that part of a protocol, and not implementing it at all in the base class (except perhaps to log that the method must be overridden to return a concrete type, to catch incorrect usage). I can think of a number of other possible scenarios, but enumerating all of them is unlilkely to help. 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.
—Graham
_______________________________________________
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