4 ms·

One apparently minor change in Kotlin coming from Java is that classes are final by default, and can be made inheritable from by qualifying them with `open`, i

by pdpi 6y ago

One apparently minor change in Kotlin coming from Java is that classes are final by default, and can be made inheritable from by qualifying them with `open`, instead of being open by default and requiring This seems small, but is a major shift in mentality: Classes shouldn't be inherited from unless they were designed to be inheritable from, and this usually comes with non-trivial invariants you need to document and respect (one aspect of this being the LSP). Therefore, inheritability should be opt-in rather than opt-out.

csharptwdec19 6y ago
C# has had a similar mindset but different approach; Classes are not 'final'(in C#, 'sealed') by default, nor are methods, BUT they are not considered virtual by default. This still makes inheritance more 'opt-in' than 'opt-out', but still facilitates the use of 'container' classes. It's still open for expansion but you can't -really- change the implementation.
gHosts 6y ago
In fact, skip all the natter about subtypes and the like and think _purely_ in terms of class invariants. A class invariant holds at the end of the constructor and the start of the destructor and at the start and end of every public method. A class invariant check for the child class _must_ invoke the class invariant check of the parent class up the class hierarchy. And that is the point and the whole point of the exercise. You can utterly rely every on instance of the parent class or any descendent class obeying the class invariant for the parent class. This allows you to reason about a broader group of types without getting bogged down by concrete details.
- Noumenon72 6y ago
  What's the invariant for the problem in the article, where set_height on a square mutates @width? Seems like you don't want to prevent width from mutating everywhere, you just want to ensure it doesn't mutate during set_height.

by pdpi 6y ago

csharptwdec19 6y ago

C# has had a similar mindset but different approach; Classes are not 'final'(in C#, 'sealed') by default, nor are methods, BUT they are not considered virtual by default. This still makes inheritance more 'opt-in' than 'opt-out', but still facilitates the use of 'container' classes. It's still open for expansion but you can't -really- change the implementation.

gHosts 6y ago

In fact, skip all the natter about subtypes and the like and think _purely_ in terms of class invariants. A class invariant holds at the end of the constructor and the start of the destructor and at the start and end of every public method. A class invariant check for the child class _must_ invoke the class invariant check of the parent class up the class hierarchy. And that is the point and the whole point of the exercise. You can utterly rely every on instance of the parent class or any descendent class obeying the class invariant for the parent class. This allows you to reason about a broader group of types without getting bogged down by concrete details.

Noumenon72 6y ago
What's the invariant for the problem in the article, where set_height on a square mutates @width? Seems like you don't want to prevent width from mutating everywhere, you just want to ensure it doesn't mutate during set_height.