3 ms·
1) You're not "abstracting away" anything like that. If you're talking about operations you can abstract over `a option`, that has nothing to do with nesting.
by brandonbloom 9y ago
1) You're not "abstracting away" anything like that. If you're talking about operations you can abstract over `a option`, that has nothing to do with nesting.
2) I would consider explicitly nested option types to be a code smell. If `foo option option` happens incidentally via a module functor or something, fine, but if you ever write that by hand, you probably want to explicitly flatten that to a 3 or 4 case sum type with explicit constructor names.
3) Nested structures like this are very unlikely to have synthetic, abstract names like MaybeMaybeFoo. Instead they are more likely to have operational, domain-specific, concrete names names. These structs are likely to _already exist_, since Go lacks type inference for function parameters: You're already going to have to create types in order to talk about these things.
4) You're "manually" packing/unpacking by writing (SOME (SOME ... constructor calls and in your pattern match. The difference between &Foo{&Bar{...}} and (Foo (Bar ...)) is irrelevant. Meanwhile, pattern matching has a syntactic advantage over a `== nil` check, but again, I'd argue that intentional nesting of numerous expected absent values is a code smell. If you really need that, you'd probably employ the null object pattern, which is easy to support in Go because methods can be called on nil instances. I'll say: I've never had to do that in tens of thousands of lines of production Go.
- catnaroek 9y ago1) When I make an abstract type “foo” whose underlying implementation (hidden to clients) is “bar option”, I'm abstracting over an option type. 2) What if, in client code, I want to make a value of type “foo option”, completely unaware that foo's underlying implementation is “bar option”? Is it still a code smell? Do I have to know what abstract types defined by other people are implemented as options, so that I don't wrap them in options of my own? 3) Meh. 4) My pattern matching is completely safe. OTOH, with your proposal, you can't safely unwrap those nested structs of nullable pointers in a single step, because you need to unwrap the first layer just to check whether the second layer is safe to unwrap. --- 2) The problem exists whether there exist non-disjoint types or not. Oftentimes I do want to use nested types, because that's the way the data is naturally structured, i.e., that's what shortens the description of the operations that act on the data. Flattening the nested type into a single sum with 4 constructors would merely impose on myself of undoing the flattening every time I want to operate on this sum. 3) It's abstraction for the sake of making code easier to reuse and verify.
- brandonbloom 9y ago1 & 2) Read my comment again. My remark about functors (in the ML sense) addresses this point. I'm quite well versed in how type abstraction works. Your comment about being aware of underlying type details is completely non-sensical with respect to nesting. The problem you're worried about applies to non-disjoint union types, ie dynamic typing, not Go's typical use of type-safe pointers. Nil is type-safe in Go, there's no risk of confusing: a nil *Foo with a nil *Bar 3) You say "meh", but abstraction for the sake of abstraction is exactly what drives working programmers away from so called "better" languages. 4) Meh. Anyway, I'm done with this thread.