3 ms·

That's not what 'fixed set' means here. It's 'fixed' in the same sense as the compiler knowing what are the subclasses of a base class. Just as you can always

by platz 7y ago

That's not what 'fixed set' means here. It's 'fixed' in the same sense as the compiler knowing what are the subclasses of a base class. Just as you can always 'extend' the OOP base class by adding a subclass, you can always 'extend' an algebraic data for by adding another case. Both can be extended, but more importantly they can be enumerated.

seemslegit 7y ago
That's correct, and exhaustively enumerating derived classes at compile-time is usually a bad design either via RTTI type-switching or pattern matching (which is really just syntactic sugar for the former). It prevents for example having derived types injected at run-time in a plugin setting. Explicitly matching a subset of well-known derived types otoh is a practical compromise in many cases.
- platz 7y ago
  > enumerating derived classes at compile-time is usually a bad design Depends on what kinds of guarantees you want. At the extreme, you can make everything in the system late-bound, and then you simply have a dynamic language instead of a static one.
  - seemslegit 7y ago
    > enumerating derived classes at compile-time is usually a bad design did you deliberately omit the word 'exhaustively' here ? late-bound != dynamically typed, that's exactly the point - you wish to preserve to the ability to have types loaded at run time without knowing their exact type at compile time while still enjoying strong type guarantees. We can do without run-time loading scenarios at all and still see why this is bad, if one adds a derived class to the code base and then has to address it in a bunch of places rather than have all the new functionality localized to the class then it's a smell
jcelerier 7y ago
> It's 'fixed' in the same sense as the compiler knowing what are the subclasses of a base class. ... but the compiler does not know ? new classes are loaded at run-time all the time with e.g. plug-in systems, etc.

by platz 7y ago

seemslegit 7y ago

That's correct, and exhaustively enumerating derived classes at compile-time is usually a bad design either via RTTI type-switching or pattern matching (which is really just syntactic sugar for the former). It prevents for example having derived types injected at run-time in a plugin setting. Explicitly matching a subset of well-known derived types otoh is a practical compromise in many cases.

platz 7y ago
> enumerating derived classes at compile-time is usually a bad design Depends on what kinds of guarantees you want. At the extreme, you can make everything in the system late-bound, and then you simply have a dynamic language instead of a static one.
- seemslegit 7y ago
  > enumerating derived classes at compile-time is usually a bad design did you deliberately omit the word 'exhaustively' here ? late-bound != dynamically typed, that's exactly the point - you wish to preserve to the ability to have types loaded at run time without knowing their exact type at compile time while still enjoying strong type guarantees. We can do without run-time loading scenarios at all and still see why this is bad, if one adds a derived class to the code base and then has to address it in a bunch of places rather than have all the new functionality localized to the class then it's a smell

jcelerier 7y ago

> It's 'fixed' in the same sense as the compiler knowing what are the subclasses of a base class. ... but the compiler does not know ? new classes are loaded at run-time all the time with e.g. plug-in systems, etc.