> If John plays the good guy, I will play the bad one :) I really appreciate both - There's tons of things to learn :)
> > You should get rid of all the scope stuff for local variables. > One var in Javascript should be one local variable on the Java stack. > (if you only implement the strict mode of JavaScript 5, there is no > problem). > > For property, you should try to map them to Java field, you can use > John's hidden class > or Nashorn double tables trick and avoid hashmaps. I'll look into this - my approach was to make it work first, make it fast later. > > You should also don't use you own hierarchy of classes but try to reuse > j.l.Object, > j.l.String, etc and boolean, double, void where you can, by example > the condition of a if should be a boolean, in x + 2, 2 should be a double. > > I've some trouble to understand why your DynPrimitiveNumber is not a > DynNumber I was trying to differentiate between the primitive numbers and the boxed number objects. > and the difference between a DynAtom and a DynObject. Given I was using my own hierarchy, I needed something common (as some js operations receive both objects and primitive types). > DynObject.eq and DynObject.toBoolean should be implemented using > invokedynamic > to adapt the sequence of if/instanceof to the callsite. Do you mean something like issuing a indy instruction, and on the linker just call a static method passing the target object as an argument? > > And at the end, all predefined Javascript objects should be re-written > in Javascript, > with some native calls to Java but it will be easier for providing the > core API. > By example, for javascript Number, it should be a j.l.Double but with > it's own vtable > to add all Javascript predefined methods. > The idea is that j.l.Double and Javascript Number are the same object at > runtime but > are seen differently in Java and in Javascript. Is there any other jvm lang that do the same thing? Makes sense, but I'm kinda lost on this - Do you have any recommended paper for me to read? Thanks for taking the time :) cheers! -- qmx > > cheers, > Rémi > > _______________________________________________ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
