Java developers and researchers ERIC Allen discussed the impact of Mixin support through generic types and ended his discussion of the series of four parts consisting of JSR-14 and Tiger prizes. . Share your views on this article with the author and other readers in the relevant forum. (You can also access the forum by clicking "Discussion" at the top or bottom of this article.)
At this point, we have discussed this in this micro series of JSR-14 and Tiger's general types:
The generic type and the upcoming functional basic type of function, which are intended to be supported, and a constrained generic and polymorphic ways to limit the implementation strategies used for compilers that are strongly added to these Java extensions. These restrictions becomes the impact of the support of NEW operations to "naked" type parameters in generic types.
This month, we will explore issues that need to be resolved before you can deal with Mixin (which may be expected to be the most powerful feature), ending discussions on generic types in Java languages.
Mixin VS packaging Mixin is a class that is parameterized by its parent class. For example, consider this generic class, which inherits its own type parameters:
Class Scrollable
Don't miss other articles in this series, easily master Java generics (February 2003) Part 2, easy to master Java generic types, Part 2 (March 2003) Part 3, easy to master Java pan Type, Part 3 (April 2003)
The purpose of class Scrollable is to embed the functionality of the GUI window widget to add the functionality necessary. Each application of this generic class will inherit a different parent class. For example, Scrollable
Packaging not only needs to add a forwarding method of the functionality of the package, but it also blocks us from using the resulting rolling object (for example, we cannot pass JScrollPane to instances that need JScrollpane to need JTextPane) in the context that needs to be packaged. Method in the method). By the parent class of Scrollable, it will be parametric. When inheriting multiple superclars, we can maintain single-point control on the function involving scrolling. This can use Mixin to let us re-get some powerful features of multiple inheritance, and there is no exception.
In the example above, we can even apply constraints for type parameters to prevent it from being used in inappropriate context. For example, we may want to enable this type of parameters to be a subclass of JComponent:
Class Scrollable
Then our Mixin can only inherit the GUI component.
Mixin and generic classes: Perfect combination usually, Mixin is added to some language as a stand-alone language function, as in JAM. But consolidation of Mixin is very attractive as part of the generic type system, almost the charm is endless. The reason is: Mixin and generic classes can be considered to map existing classes to new categories.
The generic class can be considered to map their parameters into new instantiated functions. Mixin can be considered to map existing classes into a function of new subclasses. We can solve many key restrictions on other MIXIN formulas by using generic types. In the JAM extension in the Java language, Mixin's superclass type has no name; we can't quote it in the Mixin body. This limitation will rapidly cause a series of various other issues. For example, in the JAM, the programmer is prohibited from passing this as a parameter to the method; it is impossible to check such calls. This limitation has great influence because many of the most common design patterns depends on the ability to pass this as a parameter.
Consider visitor mode, where the visitor class is defined for each class in the composite hierarchy. The class typically accessed contains an Accept method that uses a visitor and transmits this to call the visitor. Therefore, in JAM, the visitor mode cannot be used with Mixin.
Specifying Mixin as generic class, we always have a parent class handle, which is the type parameters of such inheritance. For example, we can reference the parent class of scrollable as Type T. As a result, there is no fundamental difficulty when allowing this as a type parameter.
However, there is some other obvious difficulties when expressing Mixin as generic types. In order for you to preliminate some difficulties that may be generated, we will discuss several highlighted difficulties and some possible solutions.
We should first point out that before discussing any other issues, we should first indicate that the function extension of the generic type discussed last month will not be Adding Mixin's support to the Java language.
To understand the reason, consider what happens when the class of inheritance type parameters is eliminated. This class will eventually inherit the boundaries of the type parameters! For example, each instantiation of class scrollable is ultimately inherited in JComponent in the previous example. It is obvious that it is not what we hope.
In order to support Mixin through generic types, we need to obtain a generic type instantiated runtime representation. Fortunately, there are many ways to encode this information, and they are actually compatible with TiGer. Such award-rear compatible coding scheme is a significant feature of the NEXTGEN formula of generic Java (in the reference data section).
Ultra-class constructor available in us to allow the urgent problem that we want to allow type inheritance type parameters to decide what kind of super constructor we can call? Memories: Each Java class constructor must call a superclass constructor. Typically, by looking for superclass and make sure that the type checker ensures that these super-constructor calls will succeed.
However, everything we know about superclars is limited to it is instantiated by type parameters, and what kind of constructor can be used for a given instantiation, we don't have any concept. And note that the type inspector can even check if each Mixin instantiation will generate a valid super-constructor call. The reason is: In some other context, Mixin's parameters may be instantiated with type parameter boundaries.
For example, generic class JSPLITPANE
Solving various solutions discussed in the third section of our next month, the solutions proposed by the type parameters of the NEW expression are completely consistent, because the super-constructor calls and New expressions are referenced. The same class constructor. Let's review these solutions: need a (ZEROARY) constructor that is used for instantiation of all types of parameters. When there is no matching constructor, it is throws an abnormality at runtime. Contains additional type parameter comments tell us which constructors must be included in these instantiations.
Just like the situation of New Expression, the first two solutions have serious defects. There is no meaning in the class definition in the class definition. Moreover, it is not ideal when there is no matching constructor. After all, the static type check is mainly strictly prevented from abnormal.
The third solution may be a bit cumbersome, but it has many advantages. Comment type parameters, including all instantiations must have the constructor set. These comments inform us that we can reliably call what constructor can be reliably modulated. Therefore, when the type parameter T is used as a hyperclass of generic classes, the Note of T exactly inform us which super constructor can be called. If T does not contain a comment, the Type Checker is prohibited from being used as a superclass.
Unexpected methods Cover any Mixin formula will produce a very serious problem: the method name of specific Mixin may conflict with its superclass's potential method. For example, suppose class scrollable contains methods GetSize without any parameters and returns an Size object, encodes its horizontal and vertical dimensions. Now, we assume that class mytextpane (subclats of JComponent) also contain methods GetSize without any parameters, but returns an int to indicate the screen area of the object that calls it.
The resulting class is shown below:
Listing 1. Example of accidental method coverage
Class Scrollable
...
Size getsize () {...}
}
Class mytextpane extends jcomponent {
...
Int getsize () {...}
}
New scroll
Subsequent mixin instantiate scrollable
When Mixin is explicitly expressed as generic classes, unexpectedly covered issues are particularly annoying. Because the parent class of Mixin may be instantiated by the type parameters, the type inspector cannot determine all the circumstances coverage of the accident method. Moreover, it is impossible to throw a running time when the accident coverage occurs because the client programmer cannot predict this exception will be thrown. If we want to write a reliable program, then we must ban unexpected errors from running during runtime.
Another solution is one of these mutually conflict methods and parses all matched methods to reference unwell ways. The problem with this solution is that we hope that Mixin instantiation such as scrollable
ACM Sigplan-Sigact Workshop on programming language in 1998 (see Resources), Felleisen, Flatt and Krishnamurthi proposed a good solution for this issue in the context of Mixin does not belong to generic types. : Based on the context using MIXIN instantiated context to solve references to mutual conflicts. In this solution, Mixin contains such a view: which method is to be called in the case where the name is inconsistent. As the generic type of Mixin, we can apply the same solution. We only need to design some views, these views are valid in the context of generic types, and also allows backward compatibility with JVM. In the Rice JavaPLT laboratory, we have put forward such a solution in "a first-class approach to genericity".
There must be no status as a result of example, questions, and possible solutions, inheriting generic types in Java programming to include support for Mixin, but also introduced some to overcome problem. This is a typical programming language design: It can only be added by making many existing functions to be complex. In the programming language field, there is no free lunch.
