5 ms·

There are alternatives to making references nullable by default. For example, functional programming languages often support algebraic data types and pattern m

There are alternatives to making references nullable by default. For example, functional programming languages often support algebraic data types and pattern matching. Creating the equivalent of a nullable value is one possible application of these features. Typically, the type system would make sure you can't get to the underlying value without first checking that your data is non-null via pattern matching, so the equivalent of derefencing a null pointer simply isn't possible without generating a compile-time error. Note that this idea is independent of the underlying type, so there's no particular reason you couldn't have a type system that could wrap an OO class type in an algebraic data type. Unfortunately, for now, these ideas seem to live in different worlds: I know of no mainstream OO language that has anything close to the power of algebraic data types and pattern matching that is commonly available in functional programming languages. But this is one way you could have an OO-friendly language with powerful data structures and without relying on the idea of a nullable reference.

tel 16y ago
This was the first thing I thought of. Addition types with pattern matching (which enable Maybes) both provide safe options for these data types. An example Haskell type that keeps the surface idea of nulls (via Maybe having an object) might be something like: List a :: Cons a (Maybe (List a)) Tree a :: Branch (Maybe (Tree a)) (Maybe (Tree a)) The type system removes the concept of 'dereferencing nulls' while maintaining that if the pointer isn't null it still must be the (polymorphic) type a. Of course, the simpler implementation unfolds the addition type inside Maybe and is more like: List a :: Cons a (List a) | End Tree a :: Branch (Tree a) (Tree a) | Leaf a
silentbicycle 16y ago
Pattern matching seems to mix really poorly with conventional OO subtyping / inheritance, though multi-methods seem like a good synthesis. (I haven't really used CLOS enough to decide, though.)
- Chris_Newton 16y ago
  I'm not sure OO fundamentally requires the kind of inheritance relationship that is familiar from languages like C++, Java and C#, though. For example, the Liskov Substitution Principle is phrased in terms of a subtype relationship between two types. This is a logical relationship rather than a physical one: it is about whether both types present the same interface in terms of (some aspect of) their state and behaviour, and therefore generalised code can be written that interacts analogously with instances of either type. This subtype relationship need not be realised via a subclass relationship, which is a physical relationship related to the mechanics of inheritance hierarchies and so on. I don't see any problem with mixing pattern matching and OO, if you allow a representation as an algebraic data type as one view of a class and provide a mechanism to convert between them in some suitable way. Indeed, I'm fairly sure I've seen papers investigating this approach, though I'm afraid I can't immediately remember what the authors called it so I could look them up; if anyone knows what I'm talking about, please post citations if you have them.
  - silentbicycle 16y ago
    Late reply to a late reply. While I think you're probably right, if I'm already representing things with algebraic data types, I'd rather just skip using OO altogether.

tel 16y ago

This was the first thing I thought of. Addition types with pattern matching (which enable Maybes) both provide safe options for these data types. An example Haskell type that keeps the surface idea of nulls (via Maybe having an object) might be something like: List a :: Cons a (Maybe (List a)) Tree a :: Branch (Maybe (Tree a)) (Maybe (Tree a)) The type system removes the concept of 'dereferencing nulls' while maintaining that if the pointer isn't null it still must be the (polymorphic) type a. Of course, the simpler implementation unfolds the addition type inside Maybe and is more like: List a :: Cons a (List a) | End Tree a :: Branch (Tree a) (Tree a) | Leaf a

silentbicycle 16y ago

Pattern matching seems to mix really poorly with conventional OO subtyping / inheritance, though multi-methods seem like a good synthesis. (I haven't really used CLOS enough to decide, though.)

Chris_Newton 16y ago
I'm not sure OO fundamentally requires the kind of inheritance relationship that is familiar from languages like C++, Java and C#, though. For example, the Liskov Substitution Principle is phrased in terms of a subtype relationship between two types. This is a logical relationship rather than a physical one: it is about whether both types present the same interface in terms of (some aspect of) their state and behaviour, and therefore generalised code can be written that interacts analogously with instances of either type. This subtype relationship need not be realised via a subclass relationship, which is a physical relationship related to the mechanics of inheritance hierarchies and so on. I don't see any problem with mixing pattern matching and OO, if you allow a representation as an algebraic data type as one view of a class and provide a mechanism to convert between them in some suitable way. Indeed, I'm fairly sure I've seen papers investigating this approach, though I'm afraid I can't immediately remember what the authors called it so I could look them up; if anyone knows what I'm talking about, please post citations if you have them.
- silentbicycle 16y ago
  Late reply to a late reply. While I think you're probably right, if I'm already representing things with algebraic data types, I'd rather just skip using OO altogether.