Lambda the Ultimate

Anyhow, got it to work. Guess the biggest complaint I'd have is the inability to currently add state (i.e. properties) to the classes. In addition to adding methods, visitors often require further state information to achieve their aims.

On a different note, I started reading a little on IBM's implementation of HyperJ. Could just be an impression, but docs that come out of IBM are usually thorough. Unfortunately, they can also be torturous when you are trying to learn something from scratch - having to read a whole lot before you can accomplish the first thing. Frankly, I learn better with an early start - even if my knowledge is very incomplete.

After browsing through HyperJ, I left with the impression that the use of external files to make the connections (-hyperspace and -concerns) creates a whole language onto itself. Might be useful and tie a lot of the loose ends that are present in AspectJ, but the whole idea of Aspects is to try and simplify things which are common concerns. I don't know that creating a whole meta language to describe the interrelationships of concerns is the way to meet that goal. But then I admit that I gave up the pursuit of learning HyperJ out of frustration - so my opinion is based on incomplete information.

After living through a few years of code maintenance, I have come to truly appreciate the utility of strong typing and some form of assertion or contracts. I have spent more hours tracking down obscure bugs caused by buffer overflow, or one method sending improperly formatted data to another, etc. Large systems build with C and C++ are obviously particularly vulnerable to this.

On the other hand, I have also frequently been faced with the frustrating situation where a class is declared as final, even though I have a clear and present need to create an off-shoot differing only slightly from the parent class. I can't, so I must copy the code (if it's available) into my project and create a whole new set of objects to work with. This "cut-and-paste" reuse does little to boost productivity or reliability.

I don't believe any modern language should be without multimethods -- we have all seen Peter Norvig's write-up on how dynamic languages greatly simplify (or do away with) some common design patterns. So I am quite excited by MultiJava.

I also like the idea of Open Classes, which would seem to allow a more Lisp-like extensibility to Java. It would certainly be nice to avoid having to reinvent the wheel every time someone is overly facisct in their class definitions. :-)

Are your comments on not liking AOP and C/C++ maintenance related? If so, how (do aspects imply non-static typing)?

Finally, are open classes in MultiJava just because they come "for free" with multimethods? In other words - what do open classes (usefully) provide that inheritance doesn't (I can't think of a good example where you couldn't use inheritance - legacy code can't use the new methods, or it couldn't have been compiled before)?

Finally, are open classes in MultiJava just because they come "for free" with multimethods?

There is one important difference between AspectJ and MultiJava that I did not mention. AspectJ operates exclusively on files for which you have source code. You can not introduce methods for which the compiler does not have access to source code. AspectJ is a two way street, in that it will modify the target class when it sees fit.

MultiJava has a distinction between top level methods (i.e. introduced methods) that are internally defined and those that are externally defined. Internally defined functions are equivalent to defining the method directly within the class. So these would be equivalent in results for the compiler:

class MyClass {
   void myMethod() { }
}

and

class MyClass {
}
void MyClass.myMethod() { }

Although you're allowed to pull the methods out of the body of the class, the compiler generates the same code - all within the class being defined.

If, however, you define the top level method in an external file (must be named the same as the function myMethod.java), then mjc takes a totally different approach. A set of new classes are generated that are used by the classes that "include" that external definition. These classes do the delegation for you, similar to how you would go about doing a manual delegation. The advantage, of course, being that the class calling the included method calls just invokes them like they would if they really were part of the class receiving the message.

" .... the problem you describe about final classes can (always?) be solved by delegation. The only problem, apart from the typing involved, is that the new class cannot be used in code already written for the old class... "

Unfortunately, most of the times where you do wish to add functionality to an existing class, you are trying to interoperate with a world of code written with just the knowledge of the old class. As we all know, programs spend most of their lives in maintenance/extension mode -- where concepts like open classes and multimethods can really be a big productivity win.

The problem with delegation in my mind, is that Java's single-inheritence model makes it quite tedious and error-prone to delegate to internal classes in cases where you wish to be able to treat the new variant as an instance of the old class (e.g., to be stored as part of an existing collection or whatnot.)

Delegation becomes even harder when the original architecture did not anticipate this eventuality, leaving critical functions as protected visibility so you can't adequately wrap the class the way you need to.

As you point out, Interfaces are a good way around this. But again, you are forced to re-implement much of the code, since the interface is not permitted to provide implementations of the code.

So, you are correct that we can reach the result we need, the problem is that it involves a lot of tedious duplication of work, and a lot of potentially error-prone "instanceof" and "case" stuff to dispatch to the right object in these cases.

My concerns with AspectJ (note: Not AOP in general) are mostly based on Oleg's posting, in which he discusses the problem of "knowing" what order different tangled join-points are executed in (see his example on adding a "debugging" aspect.) Until this is clarified in some way, I don't see how we are gaining much through the use of constructs like those of AspectJ (though to be honest I have not played with them much either.)

My impression is that gains we get by weaving aspects across modules and classes may be significant, but the ambiguities introduced by weaving aspects into the same join point (in a procedural context) may make debugging and so forth difficult.

I'm happy to be proven wrong -- anyone with strong AspectJ feelings, please post and tell me to go dunk my head! :-)