The way that most modern languages handle what C used to do with method-pointers is with closures. Exactly what that means for a language like Java is being experimented with in places like Groovy. Much like how entity beans are a joke -- giving all of J2EE a big black eye -- and the standard is moving over to what actually has been proven to work (a-la Hibernate), I agree with Dain that I don't really trust Sun to get it right yet; I'd rather see "real-life" solutions for a while before it gets mixed into the platform... We've lived with XDoclet before getting annotations, and libs for doing "enums" before JDK1.5, we can live without closures for a bit longer. (Said by someone who hates to leave Ruby and Python for Java largely because Java doesn't have closures.)
-Jim Moore -----Original Message----- From: Dain Sundstrom [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 27, 2004 12:53 PM To: Jakarta General List Subject: Re: Future JDK features 2 items On Oct 27, 2004, at 1:10 AM, Danny Angus wrote: > > Dain wrote: > >> If you want method pointers today, just get a good byte code >> generation tool. > > Yeah I know, and I seriously believe that workarounds such as this do > more to harm the so-called "purity" of Java than providing explicit > language level mechanisms for method pointers. I understand what you are saying, but do you believe that Sun could actually get such a feature right? My guess is they would slap so many coding restrictions and security checks around this feature to make is most useless. So, yes, I am arguing that no feature is better than a poorly implemented feature. -dain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
