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.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to