I take a slightly different approach in jSuneido. Standard operations (like "add") are implemented by static methods. The methods check for instanceof a jSuneido object and if so cast and call a virtual method. The static operation methods also check for Java types like Int or String. This means I can use these kind of simple Java types without wrapping them. (Suneido doesn't allow operator overloading, which simplifies this.)
I have not looked at performance yet (more concerned with getting things working) so I have no idea what the implications of this approach are. Presumably there is less memory usage with not wrapping common Java types. But maybe the static methods won't inline very well? And there is the cost of the type checks. On Jun 6, 2:40 am, Alessio Stalla <[email protected]> wrote: > On Sun, Jun 6, 2010 at 1:02 AM, John Cowan <[email protected]> wrote: > > On Sat, Jun 5, 2010 at 12:27 PM, Charles Oliver Nutter > > <[email protected]> wrote: > > >> I also see something else I find interesting: EObject apparently > >> implements dec() and is_ge()...I'm guessing you have implemented a > >> full set of numeric operators on EObject so that when they're > >> explicitly provided by a subtype it can be no more than an interface > >> or abstract dispatch? We've thought of doing the same for JRuby, but > >> were unsure whether it would be too cumbersome. The essential idea > >> would be that the default implementations would proceed to doing a > >> dynamic dispatch while the overridden versions would provide the > >> implementation in-place, perhaps with a guard in case someone > >> monkey-patched them. It would reduce most math operators against core > >> types to static calls (+ a two-field object comparison for the guard) > >> and greatly improve their inlinability. > > > That's what Jcon does. There are about 150 methods defined on the > > root class vDescriptor, most of which do nothing or throw errors. > > Jcon is a very interesting early JVM implementation of the Icon > > language, which is dynamically typed and has non-LIFO flow control; it > > was written back in 1999, and doesn't provide (AFAIK) any escape to > > Java: the JVM is treated as a pure implementation target. > > ABCL adopts a similar approach, too. It has a root class, LispObject, > with many methods which in their default implementation signal a type > error. > ABCL is a Common Lisp implementation for the JVM. > > -- Alessio -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. 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.
