On Oct 12, 2010, at 1:06 AM, Jochen Theodorou wrote: > John Rose wrote: >> conversation leads to the concept of a "categorical superclass". I'm >> pretty sure a number of people on this list have worked out the >> details. It would be good to discuss this, and see if method handles >> and invokedynamic can play a supporting role. > > is there anything explaining a little bit more detailed what a "categorical > superclass" is?
Ahhh... that's easy: It's a typo for "categorical subclass". > [...] >> There are two features >> because even if M specifies an override for m(T), there must be a way >> for the override code to access the original S.m(T) to emulate >> "super.m(...)". > > MethodHandles cannot do that? Why not doing the invocation through a > MethodHandle in general there? Yes, using a vtable-like display (array or map) of method handles is an alternative to something with an interface that is specific to S. > Per default it would be the one calling super in the end... or if exchanged > it would be the one we placed in. Yes, that's true, as long as the user saved the initial value somewhere if a "super" call was intended somewhere. (That's a natural way to do it if you present the metaclass as a vtable-like structure.) > > [...] >> Basically, K's constructors have to pass the verifier, but >> they cannot constrain future users of K beyond the limits naturally >> imposed by the constructors of S. > > you mean you want to enable super(x,y), and super has no constructor that > could take x or y? Yes, but maybe after language-specific conversions there is a constructor which can be made to fit. Or maybe there are several constructors that could take (x,y) and you want to apply some sort of decision tree (either Java overloading rules or something else). All that sort of stuff has to be moved outside of the constructor call and wrapped around the new(...) call that creates the object. The categorical subclass must provide the "hooks" needed to select which entry point to use, and then use it. In Java, selecting a class's constructor determines two choices at two steps: (step 1) a call to a particular super-class constructor selected by the constructor, and (step 2) execution of the subclass constructor body. I suggested that the categorical subclass needs constructors that match the superclass. This allows the selection of subclass constructor to imply a free choice of step (1). I suppose the remainder of the initialization (step 2) needs to be freely and independently specified as a method handle (or other blob of code). This seems to imply that the step 2 behavior should be an additional parameter to the categorical subclass constructor. > Groovy does not allow for such things atm. When we encounter a super(...) > call, then we go into a switch construct, and ask the MOP about which > constructor to invoke. This of course requires us to write the constructor > calls into the bytecode... there is no other way atm, the doubled meaning of > register 0 does not really help in this respect.... anyway... most of the > time this works good enough for us. So what we do is basicallylet the MOP > return the constructor number (defined by sorting) and modifying the > arguments in an array. For the actual call we then unpack the array and make > the call native. If someone is adding a new constructor, then this > constructor cannot be used by super(...), but it can be used through "new ..." Right, not super(...) from a sub-sub-class. The guy that makes such a call needs to know a lot about the structure of the (categorical) sub-class. I suppose part of such a design would include a generator which would make a sub-sub-class with a desired set of public or protected constructors (and other features like methods and fields). > btw... I think the state with MethodHandles was, that they cannot call to an > overridden super method.. please correct me if I am wrong here. No, MethodHandles.Lookup.findSpecial can do this. (But not for <init> methods.) > Sure, there is an easy solution for this, just create a helper method to do > that job for you... but it bloats the bytecode extremely. More bytecode means > longer class loading and verification times and more work for the JIT. It > would be nice to not to have this restriction Bloats the bytecode, and (worse, as I think John Wilson pointed out) bloats it even in the common case where you never actually use the 'super' construct. Check out findSpecial: http://cr.openjdk.java.net/~jrose/pres/indy-javadoc-mlvm/java/dyn/MethodHandles.Lookup.html -- John -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-langua...@googlegroups.com. To unsubscribe from this group, send email to jvm-languages+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
