On May 22, 2008, at 3:06 AM, Geert Bevin wrote: > I can see a great use-case here to hook in at object > instantiation time and perform some other logic instead of calling the > constructor.
Working around constructor sequencing is probably a bad idea, though there are unsafe primitives in hotspot that serialization uses. If you are generating code for your own language's objects, build an initialization protocol which takes place after all constructors are run. (If the constructors get in the way, just make them be no- ops.) Then you won't need to inject code into the constructor sequence. And, of course, consider using protected constructors and factory methods to build your language's objects. On May 22, 2008, at 5:27 AM, Rémi Forax wrote: > Remplacing an invokeSpecial by invokeDynamic (invokeDynamic on > java.dyn.Dynamic) > will lead to code that will be rejected by the bytecode verifier :( > Thus there is no support for invokeSpecial. For support for invokespecial, look at MethodHandles.unreflectSpecial. This would allow dynamic language compilers to implement super.foo(). A reflective caller check during method handle creation will ensure that nobody gets to create a super.foo() capability unless they would also be able to use the corresponding invokespecial call directly. Thanks, -- 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-languages@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
