On Tue, Sep 22, 2009 at 9:32 AM, Don Cohen don-sourceforge-xxz@isis.cs3-inc.com wrote:
Alessio Stalla writes: > In other > words, the JVM is natively object oriented, it has no concept of > function, only methods. This is not, in my mind, the same thing as being natively object oriented. A function could be an object too. If you wish I'll be happy to view a function as a method of a class that is nothing more than a container for that function.
Exactly, we agree. The point I was trying to make is that the container class must exist, so the compiler must create it.
> It doesn't only supports loading from files. Out of the box there are > classloaders that know how to load code from arbitrary URLs, from JARs > inside WARs (packaged web applications), and more; you can write your > own and even generate code on the fly if you want, but, no matter > what, the end result will always be a class with methods holding the > code. Good, so you should be able to write a "classloader" that supports creation of an anonymous subclass of "compiledFunction" (of which there might never be any instances) given a single argument of type byte vector.
Anonymous classes don't exist in the JVM, but apart from that, you have just described the abcl classloader ;) However, my original point was not about the general compilation model of abcl, which is more than fine by me; rather, it was about the specific fact that the generated code includes instructions to load the other code it needs (compiled local functions), and I think that is a Bad Idea and we can use classloaders properly to avoid it.
Bye, Ale