Last updated:
Nov 16, 2004
m2 extends m1, m2 can access to the fields defined in m1. Doesn't it threaten the information hiding ?
c extends a, b" does not determine whether a extends first or b.
Isn't it problematic ?
Yes, MixJuice is an aspect-oriented language in a broad sense. It is possible to make codes that crosscut some classes in a separate module.
However, the idea of MixJuice differs from that of a typical aspect-oriented language AspectJ. AspectJ emphasizes the separation of aspects, which are different from the main functionality of the program, such as debugging, synchronization or performance, but MixJuice does not.
The problems MixJuice try to solve are rather near to those which Hyper/J try to solve. Traditional imperative languages or object-oriented languages force the only way to create modules (procedures or classes) to programmers, Hyper/J and MixJuice make possible free ways to create modules.
Moreover, the most important points of designing MixJuice are the simplicity of language specification and the safety of linking modules. MixJuice is significantly different to other AOP systems in these points.
It seems that difference-based modules are applicable not only to object-oriented languages but also to imperative languages, logical languages, hardware description languages, etc. Most programming languages name some kinds of code units. The idea of MixJuice's module mechanism is simple; one adds a difference to a code element corresponding to a name in the original program. Therefore, difference-based modules are applicable to most programming languages.
For example, dm-elisp is a kind of emacs-lisp to which difference-based modules are applied.
There are some languages to which the module mechanism of MixJuice is not applicable. For example, since term rewriting systems do not have names on code units, difference-based modules are not applicable.
Among problems of multiple inheritance, name collision problem has been solved completely by introducing fully qualified names of fields and methods.
Another problem, or semantical collision can be solved by applying the ideas of Design by Contract and Behavioral Subtyping to difference-based modules. (See this paper for more details.)
However, it is certain that for human beings tree structures are easier to handle than general graph structures. On the programming in MixJuice, we do not recommend a complex multiple inheritance of modules. Any inheritance graphs of modules should be programmed in form as simple as possible.
The ideal inheritance graph of modules is in the form that its inheritance depth is shallow and width is wide. If an inheritance graph has such a form, maintenance of the program should be easy.
Java has the package mechanism besides the syntax of class, but their division of responsibilities is not complete. Both package and class share the role of name space. MixJuice classifies and divides the responsibilities of class and module, in order to make the language specification simple.
As it is said in XP community, it is not worth spending time to modularize considering extensibility and reusability from the beginning.
It requires energy to keep extensibility and reusability high for any languages including MixJuice. If you modularize to have high extensibility and reusability thinking about future development, it is not paid until the program will actually be extended and reused. Programmers should think about the trade-off and allocate his/her time accordingly.
A good point of OOP is that it is needed only to write a class modeling a domain object in order to make a program with high extensibility and reusability to some degree. That is, since the equation "class = module" is valid at least approximately, merely designing a class leads to a modestly good modularization. It is one of the merits of object-oriented paradigm.
The inherited merit is one of the MixJuice's merits. If you don't have a time to be annoyed by the perfect modularization, you can make a class per module as you do in other languages. Only doing so might make modularization accomplished to some degree. You can wait rethinking about modularization until the time when a problem will appear during development and maintenance.
The task to change modularization is called refactoring. We hope there will be tools to support refactoring in MixJuice, in the future.
You are right. The object-oriented design and the refactoring are important activities in MixJuice programming, too.
Traditional object-oriented languages have been getting similar criticism: "A program is hard to read because a class definition is devided into superclass and subclass." There are two responses.
The first one is a practice of Design by Contract. If each public interface of class and method is clarified, there is no need to read its implementation codes. Thus, it is not a problem even though the inner implementation is scattered. In other words, information hiding make the unnecessary names of classes and methods invisible, and readability of program increases. This is also true for difference-based modules.
The second one is a documentation using UML or something. Since the problems treated by object-oriented languages are much more complex than those treated by old languages, it is impossible to understand the whole picture by reading the source-code. Then, it is needed to understand with UML or something. This is also, again, true for difference-based modules. If you use a layered class diagram, which is an extension of UML class diagram, it is possible to express visually and in easy-to-understand manner how a module extends the program.
We think multiple inheritance of class is a necessary function for object-oriented languages. However, as far as MixJuice is a language executed on the JavaVM, there is no plan to support it. If one implements a multiple inheritance of class mechanism on the JavaVM, there is no way to avoid slow execution speed.
Szyperski, C.A.:
"Import is Not Inheritance, Why We Need Both: Modules and Classes",
In Proc. of ECOOP'92.
It is said that inheritance of class should not be used instead of import of library in the paper cited above.
It is, however, a common practice of designing a programming language to realize essentially different concepts in one language mechanism. For example, Java uses class as a unit of information hiding, a unit of defining type, a unit of semaphore, a unit of allocating memory, etc. Unifying many features in one language mechanism in such fashion make it possible for the language to satisfy simultaneously the contradicting requirements: multifunctionality and simplicity of the language.
MixJuice separates the function of name space from class, and unifies name space and the differential programming mechanism instead. It seems succeeded.
Import and inheritance are similar by nature as functions. In Eiffel culture, its inheritance mechanism is used as a library import mechanism willingly. For example, when a class uses standard I/O library from inside, it inherits the class which provides the function. (Note that Eiffel does not provide implicit inheritance of library interface.)
MixJuice should not be used "outside sandbox" or "for dynamically loading unsafe codes". From the security viewpoint, every class name, field name and method name defined in MixJuice should be understood as "public".
The problem of name collision is solved by introducing the FQNs of methods.
There are, however, kinds of collisions not solved only by the FQNs of methods.
For example, let's think about the following situation:
an abstract method foo is defined in module m1, sub-modules m2 and m3 implement m1 each, and there is a sub-module m4 inheriting both m2 and m3.
Then, from the standpoint of m4, either implementation of foo in m2 or m3 is hidden by an override.
If there is a demand to use in m4 both implementations of foo from m2 and m3,
we might need to have a mechanism like the method rename of the Eiffel language.
In the future, the mechanism may be implemented in MixJuice.
The syntax was designed as it is, because the Java language has the problem that it uses "." for both the punctuation character of package names and the access operator for members. If the problem will be solved, the syntax will be acceptable. (Using an alias of a name space for prefix like XML might make the syntax clear. We may have it in a future version.)
MixJuice can minimize the depending name space, the probability that name collision occurs is supposed to be much lower than those of other object-oriented languages. Therefore, we suspect that there are not so many chances for programmers to specify the FQN in real programming activities.
m2 extends m1, m2 can access to the fields defined in m1.
Doesn't it threaten the information hiding ?
In the context of MixJuice, "m2 extends m1" should be understood as "m2 is defined inside the class m1" in the context of Java.
From inside, all names defined outside are accessible.
In some sense, all names in MixJuice have access modifiers "protected".
As the protected fields of superclass are visible from its subclasses in the Java language, all names of super-module are visible from its sub-modules in MixJuice.
It is needed, then, the programmers whose modules extend m1 should be conscious of being not a user but an implementer of m1 while they are programming.
Though it is not in the current language specification, "final module" like mechanism might be in MixJuice, in the future; it is a module which does not allow to create its sub-module, like "final class" of Java. Then, the names defined in a final module are supposed to be all "private".
The final module mechanism is a mechanism for foolproof. If a programmer writes a program depending on the inner implementations as well as the outer interfaces, the one who suffer a penalty is obviously the programmer him/herself. When an inner implementation is modified, the programmer must rewrite his/her program.
We plan to implement the assertion mechanism like one in Eiffel, then the programmer who writes programs depending on implementations will suffer more penalties. The programmers who only use outer interfaces should care about only preconditions, but the programmers who use also the knowledge of inner implementations should care about postconditions and invariants also. In other words, those programmers are forced to program with stronger constraints.
c extends a, b" does not determine whether a extends first or b.
Isn't it problematic ?
In the languages like CLOS, the declaration "c extends a, b" is interpreted as a is prior to b.
It is called "local precedence order".
In these languages, the local precedence order is preserved with a linearization.
In MixJuice, because we attach importance to the protection from link-time errors for an end user who combines modules, we do not include the local precedence order in the language specification. Let's think about the following example:
module c extends a, b {...}
module d extends b, a {...}
In the case where an end user combines modules c and d, it impossible to linearize as preserving the local precedence order.
In languages like CLOS, it is error, in the case.
If there is a merit which exceeds the demerit that it might cause a link-time error, we might take the local precedence order in the language specification.
It is certain that inheritance of implementation and inheritance of interface are different concept, but we disagree your point that they each should have own language mechanism. Since subtypes usually have common behaviors to their supertypes, subtypes should inherit the implementations automatically for programmers' convenience.
Moreover, comparing with preparing two mechanisms, preparing only one mechanism, or class inheritance mechanism, have a big merit that the language specification is simplified.
We know there are cases that one wants to inherit implementations without subtyping or one want to make a subtype without inheriting implementations. For the former case, a mechanism like private inheritance of C++ can be useful. For the latter case, it is desirable that the implementer of the framework should define specification modules and implementation modules separately. If the framework is not in such a fashion, it is possible to neglect the implementation of superclass by overriding every method.
The answers vary with the module relations on which you focus attention.
Answering with an image of the Java's nested class, sub-modules are inside super-modules. From a sub-module all the names of the super-module can be accessed, and it is corresponding to the fact in the nested class case that from an inner class all the names of the outer class can be accessed. Generally, the outer modules are for abstract public interfaces, and the inner modules are for concrete implementations. In other words, from the viewpoint of "relationship between modules that inner one is hidden", a super-module hides a sub-module. Therefore, sub-module is inside super-module.
This can be understood with comparing with the nesting module relations of the real world. For example, there are modules, a hard disk, a motherboard, etc. in a PC case, and each of them also consists of smaller modules. The outside modules tend to hide inside and provide functions with higher abstraction. As the example shows, super-modules and sub-modules are corresponding to outer modules and inner modules of real world respectively.
In contrast, concerning "accompaniment relation" and "dependency relation", the correspondence of MixJuice modules and the real world is different.
In the real world, a movement of an outer module causes a movement of the inner modules. To put it simply, the inner modules accompany the outer module. On the other hand, in MixJuice, specifying a sub-module at link time, the super-module is also linked automatically. In other words, the super-module accompanies the sub-module. The relation has the opposite direction to the nesting relation.
At last, how is it seen from the viewpoint of "dependency relation"? In the real world, a motherboard module, for example, has a CPU module. Which does depend on another, a motherboard or a CPU? (Think about the case that both motherboards and CPUs are provided from various makers and they all have compatibilities.) From the MixJuice viewpoint, both a specific motherboard product and a specific CPU product don't depend on each other. The fact that they can be connected results from that both of them implement the "specification of CPU socket" correctly. Using MixJuice syntax, we can express:
module cpuSpec {...}
module motherBoardSpec {...}
module cpuImplementation extends cpuSpec {...}
module motherBoardImplementation extends cpuSpec, motherBoardSpec {...}
The "specification of CPU socket" is expressed in MixJuice as a specification module. However, the specification in the real world is merely written on the paper, and it does not exist normally as a substantial module. Thus, a dependency relation in MixJuice does not correspond to a real world module relation.
We can summarize as the following:
hiding relation: super-module is outside, sub-module is inside,
accompaniment relation: super-module is inside, sub-module is outside,
dependency relation: sub-module depends on super-module, no correspondence in the real world.
MixJuice doesn't have any kinds of generics mechanisms, which generate various modules from a template module with types or static values arguments.
It is impossible now, but we plan to implement a mechanism to make a copy of class hierarchy, in the future.
It is impossible now, since the name of the class, which is the target to make an addition of a difference is fixed. We plan to implement a mechanism to change the name of the target class.
No, you can't. A dynamic loading of a class is possible as in Java.
The class inheritance should be used with is-a relations, and it should not be used as a tool for differential programming without careful consideration. On this point, MixJuice is same with C++ or Java. (In Smalltalk community, we are not sure but maybe because it has no static type checking, class inheritance is used as a tool of differential programming.)
No, there aren't in the current MixJuice, but we think there should be. People may think the following program can be a substitution of before advice.
module m1 extends m0 {
class C {
void foo() {
m1BeforeFoo();
original();
}
}
}
The intention of the programmer who wrote m1 is probably that "I want doBeforeFoo() be executed before the execution of the body of foo."
It can be realized.
However, there is a case that it is insufficient.
Another programmer may need to add a process between "the process which his/her super-module adds before the body of foo" and "the original body of foo".
(This kind of requests is a usual one.)
He/she may write the following code, but it doesn't work:
module m2 extends m1 {
class C {
void foo() {
m2BeforeFoo();
original();
}
}
}
By the code above, the process m2BeforeFoo() is executed before m1BeforeFoo().
This kind of problem can be solved if the framework prepares the before hook in advance.
module m0 {
define class C {
define void beforeFoo(){}
define void foo() {
beforeFoo();
defaultFooBehavior();
}
}
}
However, it might not be predictable at the time of constructing a framework whether it will need to have hooks for before, after and around. Moreover, it is impossible in reality to have before, after and around hooks in every method because of possible needs. From these reasons, we are considering to have a certain language mechanism to treat before, after and around hooks.
It is usual for language researchers to propose a new language as an upper compatible language of an already existing language. If one makes a new language upper compatible to Java, it is easy to move from Java and it assures that the descriptive power of language is not less than that of Java.
On the other hand, it is definitely hard to include the idea of MixJuice's module mechanism keeping consistency with Java's module mechanisms such as package, public/protected/private or nested class. Even if it is possible to design such a language, the language specification must be too complex and its implementation must be very hard, and it is impossible to make it a useful language.
A sub-module alone does not have a function, but with super-modules it provides a set of classes that has functions.
The situation is same with that of subclass in OOP. A code of subclass alone has no meanings, but with the code of the superclasses it becomes meaningful class definitions.
|
|
Last updated:
Nov 16, 2004
|