Dart 3.3(medium.com)
medium.com
Dart 3.3
https://medium.com/dartlang/dart-3-3-325bf2bf6c13
5 comments
> Dart doesn't get the respect it deserves.
For sure. Its only real use case is Flutter right now.
If Dart decided to expand things would get interesting.
That said, I really enjoy its focus on Flutter.
For sure. Its only real use case is Flutter right now.
If Dart decided to expand things would get interesting.
That said, I really enjoy its focus on Flutter.
Where it's commonly used is not its use-case. It can be used for a number of other cases.
Outside Flutter it has nothing to offer versus Java, Kotlin, Scala, Kotlin, C#, F#, OCaml, Haskell, Rust, Go, C++, ...
Lesser libraries, lesser IDE tooling, smaller community, no must have cases,...
Lesser libraries, lesser IDE tooling, smaller community, no must have cases,...
Lesser doesn't mean nothing, right?
It also doesn't mean it covers use cases that matter to most folks.
Oh, the package is apparently supposed to replace dart:html
It seems every language starts with free functions and classes (even mojo). They then realize that isn't so great: third parties are at a syntactic disadvantage (no dot fn's). And then, the language designers "fix" the problem with extension methods. Now you have three different function kinds, and we haven't even broached async.
Why not have only structs, free functions, and UFCS?
Why not have only structs, free functions, and UFCS?
the historical expectation is that class methods will dispatch dynamically but free functions will not. so if you only have structs, functions, and UFCS you either:
1. don't dispatch on the first argument,
2. make the first argument privileged and dispatch on it, or
3. dispatch on all the arguments
the first solution is clean, but people really like dispatch.
the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.
the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.
the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.
nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html
lisps of course lack UFCS.
see here for a discussion on the lack of UFCS in julia: https://github.com/JuliaLang/julia/issues/31779
so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!
the first solution is clean, but people really like dispatch.
the second makes calling functions in the function call syntax weird, because the first argument is privileged semantically but not syntactically.
the third makes calling functions in the method call syntax weird because the first argument is privileged syntactically but not semantically.
the closest things to this i can think of off the top of my head in remotely popular programming languages are: nim, lisp dialects, and julia.
nim navigates the dispatch conundrum by providing different ways to define free functions for different dispatch-ness. the tutorial gives a good overview: https://nim-lang.org/docs/tut2.html
lisps of course lack UFCS.
see here for a discussion on the lack of UFCS in julia: https://github.com/JuliaLang/julia/issues/31779
so to sum up the answer to the original question: because it's only obvious how to make it nice and tidy like you're wanting if you sacrifice function dispatch, which is ubiquitous for good reason!
The extension type was a bit alien to me, so it’s a type with functions in it?
Also, any plans on union types? There is like no way to tell Dart when something can either by type A or type B.
I believe pattern matching is the only way at the moment.
Also, any plans on union types? There is like no way to tell Dart when something can either by type A or type B.
I believe pattern matching is the only way at the moment.
You might already know of this since you mentioned pattern matching, but there is the `sealed` class modifier which allows for exhaustive matching on class subtypes. It's very limited: https://dart.dev/language/class-modifiers#sealed
I recall there being a reason unions aren't generally implemented, though I'm not sure where I read it. It was to do with union types being unnecessarily complex for the compiler and the code they tend to produce, at no real benefit to the programmer or the resulting program. Go's lack of unions is essentially based around the same reasoning.
It looks like it's an open discussion for Dart, but I can't see any explicit plans for an implementation.
I recall there being a reason unions aren't generally implemented, though I'm not sure where I read it. It was to do with union types being unnecessarily complex for the compiler and the code they tend to produce, at no real benefit to the programmer or the resulting program. Go's lack of unions is essentially based around the same reasoning.
It looks like it's an open discussion for Dart, but I can't see any explicit plans for an implementation.
The sealed class with the switch case pretty much solves my issue cleanly, thanks!
Nice, I know hardly anything about Dart so I’m glad what little I know was of use.
The improved Web interop looks really nice.
Dart is evolving so quickly!
Dart is evolving so quickly!
Dart is actually fairly nice to use. It's a shame it will probably end up in the Google graveyard in a few years.
I don’t actually think it will, they have invested a lot in it and some of their products are still using Dart.
> This package exposes browser APIs. It's generated from the Web IDL definitions and uses recent Dart language features for zero-overhead bindings.
Dart doesn't get the respect it deserves.