If I'm understanding, Jochen is working with a definition of "assume" that's different from everyone else's. I'd use the term "guess" for where he uses "assume" — that is, I can guess it is an int and then default to other behavior if it turns out otherwise.
~~ Robert Fischer, Smokejumper IT Consulting. Enfranchised Mind Blog http://EnfranchisedMind.com/blog Grails Expert Retainer Services http://smokejumperit.com/grails-retainer/ John Wilson wrote: > 2009/11/2 Jochen Theodorou <[email protected]>: >> John Wilson schrieb: >> [...] >>> It's virtually impossible to do effective type inferencing with Groovy >>> semantics. E.G. with >>> >>> int a = 1 >>> int b = 2 >>> def x = a + b >> I can assume x is int. But I am not free in assuming that the plus >> method is really hat I assume and that x will get the right type. So I >> need alternate paths. > > No, you can't assume x is int. For example, it's perfectly reasonable > to override the arithmetic operations to return long if the operation > would otherwise overflow. There is nothing in the Groovy language that > says that the result of adding two ints is an int (or at least there > wasn't a couple of yeas ago - has that changed?). > >> [...] >>> I have never seen any way of doing unguarded direct method calls in >>> Groovy. It is possible to generate synthetic helper methods on a >>> compiled Groovy class which can be safely called directly but these >>> helper methods need to do checks before they can pass the call on to >>> the target method; so you are, in effect, doing guarded calls. >> yes. I don't intend to change the semantics of Groovy in that area, so >> every call is guarded in some way. But how guarding is done is important >> too. >> >> [...] >>> Still, Jochen has been thinking about this for longer than I have - so >>> maybe he's seen something I've missed. >> I found out the guarding itself is not so bad. hotspot can remove many >> of those checks. The important part here is that the guards are in the >> call site or else it is very fast anything but monomorphic. > > > Yes, Hotspot can be pretty good at optimising out guards. My > experience is that they don't actually have to be at the call site - > Hotspot inlines code quite readily so if you put it in a helper method > it gets inlined quite quickly and then treated in the same way as if > it was generated at the call site. > > John Wilson > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
