On Dec 10, 2008, at 2:50 AM, BGB wrote: > pardon my ignorance, but is there any plan to allow dynamic slot/ > field access?...
Yes, but not directly in this project. The dynalang.org project builds such things on top of Java. Invokedynamic (and later interface injection) will allow such things to be treated almost as if they were built into the JVM. > ok, I am starting out just implementing my own VM with little > familiarity with this framework in general (at this point I have > little idea if it will actually be compatible), my tweak was partly > to add the ability to have usable fields in interfaces (AFAIK, this > is not allowed in standard JVMs). No. Because you can build that on top of Java with getters and setters, JVM users do not (usually) feel that the JVM is missing anything on this score. > ok, from what info I can find, interfaces in my case work a little > differently. there is actually almost no structural coupling > between interfaces and object methods. instead, a set of hash > tables is used, and the slot/method handle from the interface is > used to lookup the appropriate method in the object via the hash > tables (actually, a set of single largish hash tables is used for > managing the entire object system).... There are technical advantages to having slots as first-class objects in a VM, but most designs happily use coordinated pairs (get/set) of access functions. If you do reify slots, you might consider making them anonymous and composable in the same way that Lisp or JavaScript functions are anonymous and composable. I don't think it's enough of a win to reify them but restrict their use to implementing object (and interface) attributes. Perhaps you could unify them with local variables. But this has little to do with what we are currently aiming at on the JVM. Best wishes, -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
