Beside what Luis said about the 'when' of type checking, there seems to be a little misconception in your argument:
The nullability of a type has nothing to do with the 'when' of the type check, but is an orthogonal concept.
That Dart's current types are nullable put it indeed in a row with PHP, but also with Java and other ones.
Additional non-nullable types are one answer to it and are already discussed afaik. I would rather that Dart embraces more the functional world of algebraic data types, which would allow for things like Maybe (Haskell, Option in Scala).
But that would need more type awareness in the language, not less, as seems to be the preferred way for Dart.
In the end, a nullable reference to a string is a union type of:
String or Null
With null being the only value of Null. It would be better to avoid null in its current implicit form at all and make that union explicit. Maybe does exactly that.
KR
Det
Additional non-nullable types are one answer to it and are already discussed afaik. I would rather that Dart embraces more the functional world of algebraic data types, which would allow for things like Maybe (Haskell, Option in Scala).
In the end, a nullable reference to a string is a union type of:
String or Null
With null being the only value of Null. It would be better to avoid null in its current implicit form at all and make that union explicit. Maybe does exactly that.
On Sun, Apr 15, 2012 at 5:18 AM, Dirk Detering <mail...@googlemail.com> wrote:
Additional non-nullable types are one answer to it and are already discussed afaik. I would rather that Dart embraces more the functional world of algebraic data types, which would allow for things like Maybe (Haskell, Option in Scala).
I really really like algebraic datatypes, but I think they are unnecessary in an OOP language with subtyping like Dart. Subclasses (or implementing interfaces) accomplishes much of what discriminated unions give you in other languages. Sure, there are some differences like how each handles the expression problem and exhaustiveness checking, but I don't know of anything I can do with unions that I can't do with inheritance. Some things are more idiomatic in each flavor (pattern-matching versus visitor pattern), but they both seem to cover about the same ground, I think.
> Sadly, this is exactly what I hate in PHP.
> And I still don't understant why we can't just use Dynamic type or
> "var" keyword here.
>
> Can somebody tell me what benefits we have from type ignoring in Dart?
> Is it for performance purpose? Of for what?
> Why we allowing run code with invalid arguments?
>
> Dart was announced as optional typed, but, in fact, it's untyped at
> all.
Be careful when comparing any type system to PHP. In the example Bob
gave, the function foo() has the type int | String, which means it
might return either an integer or a string. In PHP, the equivalent
function would return a value that is both an integer and a string,
and can be used as either in subsequent operations.
Personally I don't like PHP's typelessness either. But Dart's system
of dynamic typing with optional type annotations is quite different
from that. Dart is not "untyped" at all. It does strict type checking
at runtime - if you try to do math on a string, it won't just use a
zero value, it'll throw an exception. You can also run it with type
assertions turned on, so that you'll get an explicit type error if the
runtime types don't match your annotations. And finally, you can
statically type-check a Dart program to find conflicts between your
annotations.
None of that is true in PHP.
Cheers,
Colin
I don't understand why in production we can do a thing like that :main() {var names = new List<String>();names.add('Seth');names.add(3);print(names);}Someone could tell me why the production don't care of variable's type ?
void main() {
var names = new List<String>();
names.add('Seth');
names.add(3);
print(names);
// Works when treating all elements as objects
names.forEach((i) => print(i.hashCode()));
// Breaks when treating all elements as strings
names.forEach((n) => print(n.length));
}
name.add(3);