Is there a functional language that compiles to Dart? There’s a difference between FP features & FP ergonomics. This seems like a very verbose way to go about things I’m used to being simple/easy.
Regarding sealed types, I'm not really sure why you'd choose these over type unions, in practice they're often used to describe things like events for reducers and using sealed is incredibly verbose compared to the equivalent in for instance typescript.
type Message =
| { type: 'IncrementBy', value: number }
| { type: 'DecrementBy', value: number }
| { type: 'Set', value: number };
sealed class Message {}
class IncrementBy extends Message {
final int value;
IncrementBy(this.value);
}
class DecrementBy extends Message {
final int value;
DecrementBy(this.value);
}
class Set extends Message {
final int value;
Set(this.value);
}
Record types are nearly there, but currently there isn't a way to update the records which really hobbles them in day to day use (it looks there will be record spreading coming though so this is hopefully temporary).
With primary constructors this will become something along the lines of:
sealed class Message();
class IncrementBy(final int value) extends Message;
class DecrementBy(final int value) extends Message;
class Set(final int value) extends Message;
sealed class Message() {
case IncrementBy(final int value);
case DecrementBy(final int value);
case Set(final int value);
}
I guess ultimately it depends on which language you are more familiar with...
type Message
= IncrementBy Int
| DecrementBy Int
| Set IntIn Dart, if you do:
sealed class Message {}
class IncrementBy extends Message {
final int amount;
IncrementBy(this.amount);
}
class DecrementBy extends Message {
final int amount;
DecrementBy(this.amount);
}
class Set extends Message {
final int amount;
Set(this.amount);
}
onlyOnIncrement(IncrementBy increment) {
...
}
sealed class Message {
final int amount;
Message(this.amount);
}
class IncrementBy extends Message {
IncrementBy(super.amount);
}
class DecrementBy extends Message {
DecrementBy(super.amount);
}
class Set extends Message {
Set(super.amount);
}
showAmount(Message message) {
print(message.amount);
}
It's only more verbose for the code that is defining new types. Code that is simply defining behavior (either in functions or methods) is unaffected and my experience is that that's the majority of code.
In practice, most real-world Dart code that uses sealed types also defines methods in those types, getters, and all sorts of useful stuff. Once you factor that in, the data definitions themselves are a relatively small part.
(Of course, you could argue that defining class hierarchies is already intrinscally bad. But Dart is an object-oriented language targeting people that like organizing their code using classes.)
type Message
= IncrementBy Amount
| DecrementBy Amount
| Set Amount
type Amount = Amount Int
Given the above ADT, how would you write a function that prints the amount of a Message, regardless of which case it is?
Of course, you can also reorganize you datatype so that the shared state is hoisted out into a record that also contains a sum typed field for the non-shared stuff. But that reorganization is a breaking change to any consumers of the type.
Modeling this on top of classes and subtyping lets you make those changes without touching the user-visible API.
And this Flutter binding launched a year ago by one person and then never touched again: https://github.com/fable-compiler/Fable.Flutter
It just seems like an incredibly ambitious project that appears to have very little equal but is mainly worked on by a handful of people but no corporate backing. I get the feeling that if you want to use it, you'll either be the only one doing what you're doing or among just a few people. I already use F# and feel this way about the core language itself.
Agreed.. I've definitely Googled an issue I got stuck on only to land back on my own post (lol). You need fewer people for the same amount of complexity with F#, but idk if that's somehow just translating to fewer people period?