The fact that it requires so much explanation, indicates the level of degradation in the reasoning ability of the audience. A value of a subtype shall deliver all of the expectations of its super type, because it is wearing both the hats of super type and sub type.
What part of GP's comment is not strictly logical? Does obfuscating a simple logical concept by describing it in academia-wanky-terms like Liskov's Substitution Principle make it More Logical? Or does it just make the author and their in-crowd feel more intelligent?
Yep, I wondered that for a few optimizations in Racket. It's harder than it looks, probably something about covariant or contravariant types, I gave up.
Good one, yes. It was like that in Objective-C, and in the early versions of Swift. I know you know this, but it's useful to summarize for myself:
Basically inheritance is the wrong tool for this kind of stuff. NSMutableArray inherits from NSArray, so it can be passed to anywhere NSArray is expected (upcasting).
So you design your classes and expect them to be immutable, but you can't use NSArray anywhere. Because otherwise, it'll be mutable after all. You can do a runtime check as a workaround.
(I truly believe OOP should only be taught in computer science as a relic).
The fact that it requires so much explanation, indicates the level of degradation in the reasoning ability of the audience. A value of a subtype shall deliver all of the expectations of its super type, because it is wearing both the hats of super type and sub type.
Not all all. It merely indicates that this is an strict logic approach to the topic.
https://commonplacefacts.com/2022/07/27/principia-mathematic...
What part of GP's comment is not strictly logical? Does obfuscating a simple logical concept by describing it in academia-wanky-terms like Liskov's Substitution Principle make it More Logical? Or does it just make the author and their in-crowd feel more intelligent?
In other words, immutable != read only.
In C# ReadOnlyCollection<T> and ImmutableArray<T> are two completely different things for this exact reason.
Yep, I wondered that for a few optimizations in Racket. It's harder than it looks, probably something about covariant or contravariant types, I gave up.
Isn't NSMutableArray a subclass of NSArray in a few languages?
Good one, yes. It was like that in Objective-C, and in the early versions of Swift. I know you know this, but it's useful to summarize for myself:
Basically inheritance is the wrong tool for this kind of stuff. NSMutableArray inherits from NSArray, so it can be passed to anywhere NSArray is expected (upcasting).
So you design your classes and expect them to be immutable, but you can't use NSArray anywhere. Because otherwise, it'll be mutable after all. You can do a runtime check as a workaround.
(I truly believe OOP should only be taught in computer science as a relic).
Yes, that’s ObjC, any NSMutableArray is an NSArray (and an NSObject) - classes passed by reference.
Swift is completely different. Standard arrays are structures, always mutable - value types passed by value