FYI, that's what Microsoft did with delegates, back in the J++ scandal days. I didn't agree with the political motivation but the idea has always made sense to me and I was sad to see it shoot down so stupidly by Sun.
-- Cédric On Thu, Apr 28, 2011 at 10:52 AM, Alexey Zinger <[email protected]>wrote: > As I was looking at some code today that used FP concepts with Guava > (Google Collections), I saw the same pattern I see over and over in such > Java code that strives to be expressive in a functional manner: a function > is required as a parameter for some operation and it so happens that the > code that sends that function along instantiates the Guava Function object > (or something similar, like Comparator) there and then. The look of the > code is as close to what we can expect to see in a "true" functional > language with current Java capabilities, but more often than not, the > purpose of including the guts of the function right there is to bundle the > function definition with its logical context, not because we really need to > instantiate the object in that place. In fact, typically, the anonymous > inner class expressing said function always produces identical instances. > Here's a hypothetical example. Let's assume the following gets called a lot > throughout the uptime of the program: > > final List<String> lowerCaseList = ...; > final List<String> upperCaseList = Lists.transform(lowerCaseList, new > Function<String, String>() { > public String apply(String s) { return s.toUpperCase(); } > }); > > This is quite readable, but in theory, the following would be more > efficient: > > final List<String> lowerCaseList = "..."; > final List<String> upperCaseList = Lists.transform(lowerCaseList, > toUpperFunction); > > where toUpperFunction is defined elsewhere, ensuring a more appropriate > lifespan to the instance. Is there a JVM optimization that developers can > reasonably rely on, that would effectively promote this particular > apply(String) implementation to a "static" level, so that no instance memory > would need to be allocated and reclaimed, and no constructor would need to > be called? And if not, is this on the order of magnitude, where it's > generally not a concern in performance-sensitive scenarios? > > Alexey > http://azinger.blogspot.com > http://bsheet.sourceforge.net > http://wcollage.sourceforge.net > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" 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/javaposse?hl=en. > -- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
