Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Passing a Method Name to a Method

Reply
Thread Tools

Passing a Method Name to a Method

 
 
Joshua Cranmer
Guest
Posts: n/a
 
      06-23-2011
On 6/23/2011 9:23 AM, Arved Sandstrom wrote:
> Setting things up the "OO way" in this situation, while aesthetically
> appealing, also means that you've made a deliberate design decision to
> allow for more straightforward swapping of parse logic.


Given that most of the parsers I deal with are lengthy recursive-descent
parsers, I assumed that there would have been a distinct parser object
that handled the lexing and parsing itself and furthermore that two
parsers would want to be in two separate classes. Also, since the
question was asked with the purpose of timing, I presumed that it was
fairly large and complicated parsers that were being tested for the
purpose of determining the more efficient one. As a logical consequence
of these assumptions, I would have assumed that the natural way to
implement this code is as objects, hence my surprise to not find it
implemented in such a manner.

Of course, all of this relies on my assumptions being correct.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
 
 
 
Roedy Green
Guest
Posts: n/a
 
      06-23-2011
On Wed, 22 Jun 2011 12:46:32 -0700, Gene Wirchenko <(E-Mail Removed)>
wrote, quoted or indirectly quoted someone who said :

>????? How exactly is this done? MethodToUse(actual parms)
> ...

You are presuming that Java works internally like assembler or C
where all methods exist as machine code and have an address,
determined pretty much at link time.

In Java it is much more complicated than that. Before a class is ever
used, the method reference only exists as a string. The first time it
is invoked, the class is loaded, the method offset looked up and the
caller is patched to this offset. Later code gets converted to
machine code via hotspot, and you have machine address links rather
than offsets in byte code.

That's the bad news. The good news is you can pass methods and classes
about as strings, and dynamically invoke methods with constructed
parameter lists. This is ugly and cumbersome and slow, but very
flexible. See http://mindprod.com/jgloss/reflection.html
You can do a lot with simply dynamic loading of variant classes that
support an interface. See http://mindprod.com/jgloss/classforname.html
http://mindprod.com/jgloss/delegate.html
--
Roedy Green Canadian Mind Products
http://mindprod.com
One of the great annoyances in programming derives from the irregularity
of English spelling especially when you have international teams.
I want to find a method or variable, but I don't know precisely
how its is spelled or worded. English is only approximately phonetic.
Letters are randomly doubled. The dictionary often lists variant spellings.
British, Canadian and American spellings differ.I would like to see an
experiment where variable names were spelled in a simplified English, where
there were no double letters.I also think you could add a number of rules
about composing variable names so that a variable name for something would
be highly predictable. You would also need automated enforcement of the
rules as well as possible.
 
Reply With Quote
 
 
 
 
Fuschia, President-Elect of the Bright Purplish-Green Council
Guest
Posts: n/a
 
      06-23-2011
On 23/06/2011 10:01 AM, Stefan Ram wrote:
> Arved Sandstrom<(E-Mail Removed)> writes:
>> for (i=1; i<=nRepetitions; i++)
>> ParseThisWay(args);
>> and
>> for (i=1; i<=nRepetitions; i++)
>> ParseThatWay(args);


> This is procedural programming ...


> In the general case, object-oriented programing is better,
> because it allows to add another parse method by adding
> another (third) parse class /without changing/ most of the
> other code and thus fulfills the open-closed principle,
> while procedural programming usually would required code
> changes in more places when adding a third way to parse.


I'll just mention here that functional programming, in this case at
least, also gives the advantages given by object oriented programming;
specifically, you can add another parse method by adding another (third)
parse *function* without changing most of the other code. And generally
while writing a lot less boilerplate code than Java requires, with one
interface, plus one class skeleton around each parse function, plus
relevant imports and type declarations here and there.
 
Reply With Quote
 
Fuschia, President-Elect of the Bright Purplish-Green Council
Guest
Posts: n/a
 
      06-23-2011
On 23/06/2011 12:07 PM, Gene Wirchenko wrote:
> What is the difference between the two newsgroups other than that
> c.l.j.help seems fairly moribund?


This group's not much less moribund.

It almost makes you wish for the good old days when there were thousands
of posts a month here and half of them were Twisted and people flaming
Twisted.
 
Reply With Quote
 
blmblm@myrealbox.com
Guest
Posts: n/a
 
      06-23-2011
In article <ittm03$u36$(E-Mail Removed)>, markspace <-@.> wrote:
> On 6/22/2011 12:46 PM, Gene Wirchenko wrote:
> > Dear Jav'ers:
> >
> > Maybe I will find this after searching more, but so far, no good.
> >
> > I want to pass a parameter of a method name to another method.

>


[ snip ]

> You can also do similar things with Runnable or Callable, which just
> avoids declaring a type. Since declaring a type isn't that big of a
> deal, this is usually poor solution unless you are in fact spawning
> threads and using the concurrency API directly.
>
> public class Parser {
> final private Runnable parser;
> public Parser( Runnable parser ) {
> this.parser = parser;
> }
> public parse() {
> parser.run();
> }
> }
>
> You might call this with an anonymous class rather than declaring a yet
> another type, however again that might not really be worth it. I'm
> drawing a blank here how to pass in arguments to the run method,


I don't think you can, can you? (Someone will probably be along
shortly to correct me if I'm wrong. Sort of a . )

> so I'll
> cheat:
>
> Parser p = new Parser( new Runnable() {
> private final Reader in = System.in;
> public void run() {
> new JavaLanguage.doIt( in );
> }
> } );
> p.parse(); // parse stdin


I think this is about the best you can do if you insist on (ab)using[*]
an interface whose methods don't have the parameters you want.
[*] Not that I've ever done anything like that. (Ha.)

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
 
Reply With Quote
 
blmblm@myrealbox.com
Guest
Posts: n/a
 
      06-23-2011
In article <itu79o$6oh$(E-Mail Removed)>,
Eric Sosman <(E-Mail Removed)> wrote:
> On 6/22/2011 3:46 PM, Gene Wirchenko wrote:
> > Dear Jav'ers:
> >
> > Maybe I will find this after searching more, but so far, no good.
> >
> > I want to pass a parameter of a method name to another method.
> >
> > N.B.: I do not want to pass the method name as a string. I want
> > to pass it as a pointer / reference / whatever term is used for this
> > in Java.

>
> (It's "reference." The only data items a Java program can
> manipulate are primitives and references.)
>
> Pass a reference to an object that implements an agreed-upon
> interface. See, for example, the two-argument version of
> java.util.Arrays.sort().


Sound advice IMO -- if you're familiar with the C library function
qsort, with its function-pointer parameter, comparing it with the
two-argument version of Arrays.sort may be helpful, since IMO they
provide roughly equivalent functionality, and a compare-and-contrast
with something familiar might be easier to grok than suggestions that
might be a little over the head of a novice (no offense to Gene).
In the long term learning good object-oriented design is probably
a good thing, but in the short term ....

[ snip ]

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      06-23-2011
On 6/23/2011 10:49 AM, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

> I think this is about the best you can do if you insist on (ab)using[*]
> an interface whose methods don't have the parameters you want.



I think it's a hack, but it's available if you need to use it. I'm not
recommending it, just pointing it out. Very occasionally, I could see
working with some legacy code where this might be the most economical
solution.

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      06-23-2011
On 6/23/2011 10:42 AM, Fuschia, President-Elect of the Bright
>
> I'll just mention here that functional programming, in this case at
> least, also gives the advantages given by object oriented programming;
> specifically, you can add another parse method by adding another (third)
> parse *function* without changing most of the other code. And generally



I'll just mention here that this is fairly specious. A proper OO
solution, like the ones I gave, you can add another parser just by
adding the appropriate class. The boiler plate is about two lines.


> while writing a lot less boilerplate code than Java requires, with one
> interface, plus one class skeleton around each parse function, plus
> relevant imports and type declarations here and there.



The interface is already done, skeleton, imports, etc are already done.
Just add a class with a method. What you gain in Java is type safety,
something not available in the "functional" languages I'm familiar with.




 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      06-23-2011
On 11-06-23 03:32 PM, markspace wrote:
> On 6/23/2011 10:42 AM, Fuschia, President-Elect of the Bright
>>
>> I'll just mention here that functional programming, in this case at
>> least, also gives the advantages given by object oriented programming;
>> specifically, you can add another parse method by adding another (third)
>> parse *function* without changing most of the other code. And generally

>
>
> I'll just mention here that this is fairly specious. A proper OO
> solution, like the ones I gave, you can add another parser just by
> adding the appropriate class. The boiler plate is about two lines.


Leaving aside the actual parsing code, none of the possible solutions
involve changing much code. The question is only where the code needs to
be changed.

>> while writing a lot less boilerplate code than Java requires, with one
>> interface, plus one class skeleton around each parse function, plus
>> relevant imports and type declarations here and there.

>
>
> The interface is already done, skeleton, imports, etc are already done.
> Just add a class with a method. What you gain in Java is type safety,
> something not available in the "functional" languages I'm familiar with.


Good thing you used the double quotes...because the functional languages
I'm familiar with do have type safety.

AHS
 
Reply With Quote
 
Fuschia, President-Elect of the Bright Purplish-Green Council
Guest
Posts: n/a
 
      06-23-2011
On 23/06/2011 2:32 PM, markspace wrote:
> On 6/23/2011 10:42 AM, Fuschia, President-Elect of the Bright
>>
>> I'll just mention here that functional programming, in this case at
>> least, also gives the advantages given by object oriented programming;
>> specifically, you can add another parse method by adding another (third)
>> parse *function* without changing most of the other code. And generally

>
> I'll just mention here that this is fairly specious.


Wrong.

> A proper OO solution, like the ones I gave, you can add another parser
> just by adding the appropriate class. The boiler plate is about two lines.


1. package foo;
2.
3. import bar.baz.ParseStrategy;
4.
5. public final class MyParseStrategy implements ParseStrategy {
6. public final Thingy parse (String input) {
7. // The actual implementation goes here
8. }
9. }

I count 8 lines of non-implementation code, not 2, and 162 characters,
plus eight "extra" characters per line of implementation code to indent
it properly. Versus this Clojure code:

(defn my-parse [input]
(the actual implementation goes here))

ONE line of non-implementation code and 26 characters, plus two indent
spaces per line of implementation code.

1/8 as many lines. 1/6 as many characters. 1/4 as many indent spaces per
line of implementation code. And probably a shorter & sweeter
implementation as well.

> The interface is already done, skeleton, imports, etc are already done.
> Just add a class with a method. What you gain in Java is type safety,
> something not available in the "functional" languages I'm familiar with.


Scala also gets you type safety, at a cost of a bit more boilerplate
than the Clojure example.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Passing a Method Name to a Method, Redux Gene Wirchenko Java 51 07-24-2011 10:02 AM
Passing method name to method? Arfon Smith Ruby 3 09-28-2007 03:38 PM
adding a variable name to a hash to name is part of the variable name Bobby Chamness Perl 2 04-22-2007 09:54 PM
print("my name is {name}, and {age}-year old {gender}", name, age, gender); =?iso-8859-1?B?bW9vcJk=?= Java 7 01-02-2006 04:39 PM
Re: Urgent! how to get object name, method name and attribute name based on the strings? ding feng C++ 2 06-25-2003 01:18 PM



Advertisments