> On 2 Oct 2015, at 2:28 pm, Gerriet M. Denkmann <gerr...@mdenkmann.de> 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 (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

Reply via email to