Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe04.iad.POSTED!8ad76e89!not-for-mail
From: Arved Sandstrom <asandstrom3minus1@eastlink.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: Passing a Method Name to a Method
References: <81h4075t4gfjglji1n033rb20025ebho68@4ax.com> <itu8gk$cej$1@dont-email.me>
In-Reply-To: <itu8gk$cej$1@dont-email.me>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Lines: 49
Message-ID: <R_FMp.28711$F25.8866@newsfe04.iad>
X-Complaints-To: abuse@newsgroups-download.com
NNTP-Posting-Date: Thu, 23 Jun 2011 12:06:09 UTC
Organization: Public Usenet Newsgroup Access
Date: Thu, 23 Jun 2011 09:06:08 -0300
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5573

On 11-06-22 11:30 PM, Joshua Cranmer wrote:
> On 06/22/2011 03:46 PM, Gene Wirchenko wrote:
>>       I want to pass a parameter of a method name to another method.
> 
> No you don't. You essentially want to go with the interface approach, as
> the prior responders to myself have said.
> 
> Java does not have a concept of a function pointer or method handle. It
> is possible to emulate this to some degree with reflection, but if you
> are contemplating calling Method.invoke, you are almost always doing
> something wrong.
> 
>>       static returntype ThisWay(formal parms)
>>          {...}
>>
>>       static returntype ThatWay(formal parms)
>>          {...}
> 
> Why are you having static methods (on the same class, I presume) for two
> different ways of parsing instead of using separate parser classes?
> 
At this stage of the game, considering the original problem statement, I
haven't seen any compelling arguments for not doing

for (i=1; i<=nRepetitions; i++)
    ParseThisWay(args);

and

for (i=1; i<=nRepetitions; i++)
    ParseThatWay(args);

(Note the editing from the original.) I mean, there's a strong
distinction between testing different methods of parsing (which the OP
mentioned he was doing) and coding your application to permit selection
of arbitrary parsing method.

We may be thinking at cross-purposes here. It could be that Gene,
incidental to the problem of testing parsing techniques, might really
just be curious as to whether it's possible to do something like he
asked about, i.e. function pointer-looking things. Practically everyone
else seems to have posited a Parsing U"ber-Problem which demands an
interface/pattern-based adaptive dynamic solution for production use,
and for my part I'm suggesting that if the actual issue is simply
adhoc/experimentally testing a couple of different chunks of code why
not just hardcode a couple of different methods (the engineering Good
Enough approach).

AHS