All geek questions in one place

Why is optional text input in Dart?

http://www.dartlang.org/docs/spec/dartLangSpec.pdf

The language specification for Darth is listed below.

Dart supports advanced configuration based on interface types. The type system is unsubstantiated due to the covariance of common types . This is a deliberate choice (and certainly controversial). Experience has shown that sound type rules for generics fly before a programmer's intuition . It..

  • Can anyone clarify why a cause type system is unfounded?
  • What were the authors of the Dart Lang scripts when they say that sound type rules for generics fly in the face of intuition?
+6
source share
3 answers

What were the authors of the Dart Lang scripts when they say that sound type rules for generics fly in the face of intuition?

Take a look at the related questions to the right of this. I see:

  • Why is List<Number> not a subtype of List<Object> ?
  • Why are the default shared interfaces not matching / contravariant?
  • Why can't I assign a List<Derived> List<Base> ?
  • Why can't I drop from list<MyClass> to List<Object> ?
  • Why is Animals[] animals = new Cat[5] compiled, but List<Animal> animals = new List<Cat>() does not work?

Although covariance is not sound (for many mutable types), it is a behavior that many programmers intuitively expect when they first start working with generic types.

+8
source

From Gilad Brac [1]:

You can write a tool that will scream a bloody murder about these things, but what you cannot do is stop people from starting their program.

Or in other words [2]:

the problem is that expressing a thread stream is completely and clearly more difficult for most programmers than writing code that passes values ​​around and deals with errors such as runtimes, when and if they happen. the word chosen for this difference in difficulty is that the latter is more “intuitive” than the former - I don’t think this is a particularly bad choice of word. The phenomenon is one of the main reasons dynamic languages ​​have become much more popular in recent years, the rejection of complexity when specifying static types.

It’s like there is another triangular compromise: expressive, sound, simple: choose any two for your type system. Almost everyone does not want to give up expressiveness - the graphs of objects woven in modern software can be really confusing - although any language that hopes large-scale success cannot begin at all is not so simple. Therefore, they refuse a certain (statically typed) validity and expect a lot of errors like runtime during debugging and testing.

[1] http://blog.sethladd.com/2011/11/transcription-of-quick-tour-of-dart-by.html

[2] http://lambda-the-ultimate.org/node/4377#comment-67589

+9
source

More specifically, regarding insolvency, generic types are covariant. Thus, a list of strings can be passed on to what the list of objects expects. This is not typical, because what the list of objects expects may try to add something to a list that is not a string. But telling people that when you have B as a subclass of A, but Collection <B> is not a subtype of Collection <A> is completely unintuitive.

+1
source

Source: https://habr.com/ru/post/901720/

More articles:


All Articles