4 ms·
> Records can be used in a wide variety of situations to model common use cases, such as multiple return [...] I thought multiple return was more interesting i
by cies 7y ago
> Records can be used in a wide variety of situations to model common use cases, such as multiple return [...]
I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure (Either in Haskell, Result in Kotlin and Rust).
This type of type is a sum type a.k.a. a tagged union, you could think of as Enum types where each item can have a payload.
This comes in really handy and allows Kotlin not to (ab)use exceptions for non-fatal errors.
I never had the problem with returning several objects at ones, I would simply write a class that embeds them (and in J14 I can write a record).
- Someone 7y ago”I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure” That’s or (another) one in case of failure, and not multiple return values. It returns a single value. ”I never had the problem with returning several objects at ones, I would simply write a class that embeds them” One man’s “simply” is another man’s “ugly boilerplate” or “unnecessary production of garbage objects”. You could similarly ”simpler write a class that embeds either of them”, like this: class AorB { private final Boolean itsAnA; private final A a; private final B b; public AorB(A aa) { a = aa; b = null; itsAnA = true; } public AorB(B bee) { a = null; b = bee; itsAnA = false; } ... } Ugly boilerplate? Yes. Not optimally efficient? Yes. Not as nice as the real thing? Yes. Workable? Yes. Good idea? Debatable. Java culture would use an exception if B is an error type.
- cies 7y agoI wonder what the "match" statement would look like on your example. This is exactly as you say though: ugly, inefficient, not-as-nice, yet works. And clearly debatable, especially as it goes against Java culture. The pattern could be used commonly, and clean-up heaps of code, and remove exception's hard-to-wrap-yr-mind-around flow jumps/etc, that I do hope for both tagged unions and match switches on them to be introduced. Some are already demo features IIRC.
- masklinn 7y ago> I thought multiple return was more interesting in the context of multiple possible types: like a type in case of success and one in case of failure (Either in Haskell, Result in Kotlin and Rust). That's not a "multiple return", that returns a single value which is either one type or the other. Although some languages do implement it via MRV by necessity (e.g. Common Lisp, Go, Erlang).
- cies 7y agoI dont understand the "proper use" for MRVs then. Okay we get nicer types, record types, to do them; but they are otherwise perfectly doable and with little ugly boilerplate using classes. The "either values", or sum types/ tagged unions I mentioned, are the thing that Java really lacks (and because of that the exception system got heavily abused IMHO).
- sullyj3 7y agoTechnically it's not even one type or another, eg in Rust, Some(1) and None are values of the same type, Option<i32>. What's different is the tag of the enum, or the data constructor, or whatever you want to call it.
- masklinn 7y agoThat’s the reification of it in many langage but at its core what you really want if option is T | (). And some langages do express it that way though mostly for historical reasons of not having sum types and / or being dynamically typed (and there have been rumblings in the past of making rust enum variants into proper types). Of course this is not the case for all enum types. But option / either / result, definitely.
- sullyj3 7y agoSure, namely typescript.