3 ms·

Composability comes from functions, macros, and inheritance. What does that have to do with types? "In fact, composibility is really the fundamental issue beh

by bcheung 11y ago

Composability comes from functions, macros, and inheritance. What does that have to do with types? "In fact, composibility is really the fundamental issue behind many of these problems. For example, the Store API returning nil for non-existant values was not composable with storing nil for non-existant phone numbers." That's only because you invented some abstraction that got in your way in the first place. NULL is a perfectly acceptable value in dynamic languages and even in most document store databases.

paulddraper 11y ago
This is not contrived. (1) A cache returns something or NULL. It's generic; i.e. implementation doesn't care what it is storing: integers, strings, etc. (2) A particular value of interest may be NULL or non-NULL. But now I can no longer use my generic cache and my values of interest together. A very real example of this is Java's Map interface. It's completely up to implementation on how they handle null, making interpreting null results difficult. While often you use NULL and everything works, you're still limited to a certain set of circumstances. You can't pick up thing A and thing B and just use them together. Hence non-composable.
- bcheung 11y ago
  You're conflating the meaning of NULL in that case. That's not a problem of NULL, you're using NULL to represent multiple different things. You can use exceptions to handle that scenario. cache = {} getFromCache = (key) -> return cache[key] if cache[key]? throw "not found" doSomethingWithValue = (key) -> try value = getFromCache(key) catch value = getValueFromNonCache(key) return _doSomethingWith(value)
  - dragonwriter 11y ago
    You can, but resorting to exceptions for what may not be an exceptional circumstance is a workaround for not being able to think of a way to communicate results correctly through the return value. Which illustrates the need here as effectively as the ambiguous use of null in the article.
    - bcheung 11y ago
      You don't like exceptions so your solution is creating an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have?

by bcheung 11y ago

paulddraper 11y ago

This is not contrived. (1) A cache returns something or NULL. It's generic; i.e. implementation doesn't care what it is storing: integers, strings, etc. (2) A particular value of interest may be NULL or non-NULL. But now I can no longer use my generic cache and my values of interest together. A very real example of this is Java's Map interface. It's completely up to implementation on how they handle null, making interpreting null results difficult. While often you use NULL and everything works, you're still limited to a certain set of circumstances. You can't pick up thing A and thing B and just use them together. Hence non-composable.

bcheung 11y ago
You're conflating the meaning of NULL in that case. That's not a problem of NULL, you're using NULL to represent multiple different things. You can use exceptions to handle that scenario. cache = {} getFromCache = (key) -> return cache[key] if cache[key]? throw "not found" doSomethingWithValue = (key) -> try value = getFromCache(key) catch value = getValueFromNonCache(key) return _doSomethingWith(value)
- dragonwriter 11y ago
  You can, but resorting to exceptions for what may not be an exceptional circumstance is a workaround for not being able to think of a way to communicate results correctly through the return value. Which illustrates the need here as effectively as the ambiguous use of null in the article.
  - bcheung 11y ago
    You don't like exceptions so your solution is creating an instance of a specialized class that holds my variable that has a method that acts like an "if" statement that I need to pass an anonymous function to that receives the value I already have?