And on a personal note, I used to work on the Dart team before I retired. I haven't used it since, so I'm out of touch, but it's nice to see them doing interesting work.
And on a personal note, I used to work on the Dart team before I retired. I haven't used it since, so I'm out of touch, but it's nice to see them doing interesting work.
Today we’re announcing dart2native, an extension of our existing compiler set, with the ability to compile Dart programs to self-contained executables containing ahead-of-time-compiled machine code. With dart2native, you can create tools for the command line on macOS, Windows, or Linux using Dart.
If anyone here is a fan of Dart, can you please explain, why on Earth the designers of Dart decided that this: void main() { int i; print(i); } null Is sane and good behaviour? I have explicitly...
If anyone here is a fan of Dart, can you please explain, why on Earth
the designers of Dart decided that this:
voidmain(){inti;print(i);}
null
Is sane and good behaviour? I have explicitly told the compiler that
I want an integer. null is not an integer. For a language
that has (initially) positioned itself as a better-typed JavaScript
replacement, this is just… bad.
The reasoning is that in Java or C, basic value types like int are special and cannot be null. In Dart, as in JavaScript, there is no special case, everything is an object. Every variable defaults...
The reasoning is that in Java or C, basic value types like int are special and cannot be null. In Dart, as in JavaScript, there is no special case, everything is an object. Every variable defaults to null. So it's more consistent in a way, but surprising for int.
But they going to change the language so that nulls aren't allowed by default, so the int type won't allow null anymore and if you want nulls, you write int?. So after the migration, my guess in that your example will be a compile error? Unless they decide that defaulting to zero is better.
But for now I don't think there is a way to say what you mean. Integer types allow null and it's a nuisance. You do get used to initializing number variables to zero, like in JavaScript.
I see, thanks. The Everything Is An Object philosophy makes things clearer, although it's still not something I would expect from a statically-typed language.
I see, thanks. The Everything Is An Object philosophy makes things
clearer, although it's still not something I would expect from
a statically-typed language.
A bit more background: when Dart started, it was an odd mixture between a static and dynamic language. The idea was that if you replaced all the type declarations with var, the program would do...
A bit more background: when Dart started, it was an odd mixture between a static and dynamic language. The idea was that if you replaced all the type declarations with var, the program would do the same thing. So, int causing different initialization behavior than var wasn't allowed by the design philosophy.
It's not until 2.0 that Dart became a true statically typed language, in the sense that both the reader and the compiler can rely on type declarations being accurate (or the program doesn't compile).
What does it have to do with statically-typed? If in Java, you had Cat i; System.out.println(i); you still get null despite (in your argument) I want a Cat and null is not a cat.
What does it have to do with statically-typed? If in Java, you had
Cati;System.out.println(i);
you still get null despite (in your argument) I want a Cat and null is not a cat.
In most of statically-typed languages used today this is not the case for integers. null is not a valid integer value, but it may be a valid value for an object. In C, C++, and most Pascal...
In most of statically-typed languages used today this is not the case
for integers. null is not a valid integer value, but it
may be a valid value for an object. In C, C++, and most Pascal
dialects a code like the one I've mentioned will give you a (garbage)
integer. Rust will generally not allow you to use an uninitialised
value, but if you ask it nicely (with unsafe that is) then
it will give you a garbage integer as well. In Go it will give you the
integer zero.
In fact, your post made me check something:
In Python the code x = int() results in x
being zero.
In JavaScript, the language Dart was originally destined to replace in
browsers, let x = new Number() again gives you
[Number: 0]. Which makes Dart's choice even more strange.
Ruby's Integer class doesn't have a ::new
constructor.
Lua doesn't seem to have any way to do that either.
The fact that “Everything Is An Object” makes Dart's choice
understandable, but it's not a choice I support. IMO, an integer is
supposed to be, well, an integer. Zero, garbage, 42,
whatever but not a null.
And on a personal note, I used to work on the Dart team before I retired. I haven't used it since, so I'm out of touch, but it's nice to see them doing interesting work.
From the article:
If anyone here is a fan of Dart, can you please explain, why on Earth the designers of Dart decided that this:
Is sane and good behaviour? I have explicitly told the compiler that I want an integer.
nullis not an integer. For a language that has (initially) positioned itself as a better-typed JavaScript replacement, this is just… bad.The reasoning is that in Java or C, basic value types like int are special and cannot be null. In Dart, as in JavaScript, there is no special case, everything is an object. Every variable defaults to null. So it's more consistent in a way, but surprising for
int.But they going to change the language so that nulls aren't allowed by default, so the
inttype won't allow null anymore and if you want nulls, you writeint?. So after the migration, my guess in that your example will be a compile error? Unless they decide that defaulting to zero is better.But for now I don't think there is a way to say what you mean. Integer types allow null and it's a nuisance. You do get used to initializing number variables to zero, like in JavaScript.
I see, thanks. The Everything Is An Object philosophy makes things clearer, although it's still not something I would expect from a statically-typed language.
A bit more background: when Dart started, it was an odd mixture between a static and dynamic language. The idea was that if you replaced all the type declarations with
var, the program would do the same thing. So,intcausing different initialization behavior thanvarwasn't allowed by the design philosophy.It's not until 2.0 that Dart became a true statically typed language, in the sense that both the reader and the compiler can rely on type declarations being accurate (or the program doesn't compile).
What does it have to do with statically-typed? If in Java, you had
you still get null despite (in your argument) I want a Cat and null is not a cat.
In most of statically-typed languages used today this is not the case for integers.
nullis not a valid integer value, but it may be a valid value for an object. In C, C++, and most Pascal dialects a code like the one I've mentioned will give you a (garbage) integer. Rust will generally not allow you to use an uninitialised value, but if you ask it nicely (withunsafethat is) then it will give you a garbage integer as well. In Go it will give you the integer zero.In fact, your post made me check something:
x = int()results inxbeing zero.let x = new Number()again gives you[Number: 0]. Which makes Dart's choice even more strange.Integerclass doesn't have a::newconstructor.The fact that “Everything Is An Object” makes Dart's choice understandable, but it's not a choice I support. IMO, an integer is supposed to be, well, an integer. Zero, garbage,
42, whatever but not anull.