Cross-border: type policies other than the Java model

Cross-border: The type policy other than the Java model-general Linux technology-Linux programming and kernel information. The following is a detailed description. When talking about the type and method of the Java language, the Java Community is divided into two camps. Some people like error checking during compilation, better security, and improved tools-these are all features of static types. Others prefer a more dynamic type of experience. This time, you will see some very different types of policies used by the two highly productive non-Java languages, and some methods to improve the type flexibility of concurrency in Java programming.

In the discussion of any programming language, a controversial issue is the type model. The type determines the types of tools that can be used and affects the application design. Many developers associate the type with productivity or Maintainability (I am one of them ). Typical Java developers are usually very happy to maintain the role of the type model of the Java language, emphasizing that the Java language can adopt better development tools, capture certain types of bugs (such as type incompatibility and spelling errors) during compilation, as well as performance advantages.

If you want to understand a new programming language or even a series of languages, you should generally start with the type strategy. In this article, you will see the type model in some languages other than Java. First, I will briefly introduce some decisions that must be taken into account by any language designer in the type model, focusing on some different decisions of static and dynamic types. I will show some extreme examples-static types in Objective Caml and dynamic types in Ruby. I will also talk about the type restrictions of the Java language and how to break through the restrictions of the Java type for fast programming.

Type Policy

The following types can be viewed from at least three perspectives:

The static or dynamic type depends on when the type model is implemented. Static type language implements the type during compilation. Dynamic Language is usually implemented at runtime based on the characteristics of an object.

Strong or weak type depends on how the type model is implemented. The type is strictly enforced. If any violation of the type rule is found, a runtime or compile-time error is thrown. The weak type leaves more room. In extreme cases, a weak type language (such as a hacker) allows any data type to be assigned to another type (whether or not the value is meaningful ). Static languages can be either strongly typed or weak. Dynamic type systems are usually strongly typed, but not completely.

The explicit or implicit type depends on how the language determines the type of a given object. Explicit language requires that each variable and each function parameter be declared. The implicit type language determines the object type based on the syntax and structure clues in the language. Static language is usually explicit, but not completely; Dynamic Language is almost implicit.

The following two examples illustrate the connotation of these two perspectives. Suppose you compile the following Java code:

Class Test {
Public static void test (int I ){
String s = I;
}
}

You will receive the following error message:

Test. java: 3: incompatible types
Found: int
Required: java. lang. String
String s = I;
^
1 error

Run the following Ruby code:

1 + "hello"

You will receive the following error message:

TypeError: String can't be coerced into Fixnum
From (irb): 3: in '+'
From (irb): 3

Both languages tend to be strongly typed, because they throw an error message when you try to use an object of A type structure other than they expected. The Java type policy provides an error message during compilation because it performs a static type check. Ruby provides error messages at runtime, because Ruby supports dynamic types. In other words, Java binds an object to a type during compilation. Ruby binds the object to the type whenever the object is changed during runtime. Because I declare variables in Java code rather than Ruby, we can see that the explicit type of the Java language works differently from the implicit type of Ruby.

From these three perspectives, static and dynamic types have the greatest impact on language features. Therefore, I will focus on the advantages of these two strategies.

Advantages of static types

In a static type language, the programmer (by declaration or by Convention) or the compiler (based on the structure and syntax clue) assigns a type to a variable, and that type will not change. Static types usually require additional costs, because static types (such as Java) are usually explicit. This means that all variables must be declared and the code is compiled. Cost is also accompanied by benefits: Early error detection. Static types provide much more information for compilers at the most basic level. The advantage of more information is that some types of errors can be captured earlier, and dynamic type languages can only detect these errors at runtime. If you wait until the runtime to capture these bugs, some of them will enter the production environment. Perhaps this is one of the most criticized aspects of Dynamic Language.

In another view, modern software development teams typically run automated tests, and supporters of dynamic languages claim that even the simplest automated tests can capture most types of errors. The best argument that dynamic language supporters can provide is that the benefits of early detection are less than the cost, because whether dynamic types are used or not, all tests are required.

An interesting compromise is to use an implicit type in a static type language to reduce the type cost. Open source code language Objective Caml (OCaml) is a derivative of static type Language Lisp, which can provide good performance without sacrificing productivity. OCaml uses the implicit type, so you can write the following code using the static type:
　　　　　　　　　　　　　　
# Let x = 4 + 7

OCaml returns:

Val x: int = 11

Based on the syntax clues in the expression, OCaml deduced the x type. 4 is the int type, and 7 is also the int type. Therefore, x must be the int type. Implicit type languages can have all types of Java security, or even more. The difference lies in the amount of information you need to provide and the amount of information available when reading the program. Many people who prefer static types prefer implicit types. They would rather have the compiler do this, rather than repeatedly entering the variable type in the code.

The implicit type system does not need to declare a type for a function parameter because the compiler will deduce the type of the parameter from the input value. Therefore, the same method can be used for multiple purposes.