Passing a Method Name to a Method

[Arved Sandstrom]

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.

In this particular situation, even if the code is throwaway testing
stuff, implementing it your way is either the best decision or a good
decision. After all, it's not exactly a complicated OO problem.

My point was simply that if this *is* back-of-the-envelope test code,
that using interfaces etc is not necessary. It's not inadvisable - it's
just not _needed_.

Don't mind me - the last few years I've been questioning dogma. All of
it.

AHS

 

[Nebulous]

      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 [suspected implied insult deleted]

No. None of the nasty things that you have said or implied about me
are at all true.

 

[Gene Wirchenko]

Unfortunately, you can't do this easily or efficiently (you'd need to
use the Reflection API's Method objects) in Java; what you really want
is a functional language like Clojure or Scala.

If you really must use Java, define an interface that ThisWay and
ThatWay can be instances of and which specify a parse method, and pass
an instance to the parser class's method. (The so-called "strategy
pattern".)

The reason why I want to do this is to check speed of
implementations in Java. Obviously, I have to use Java to test Java
impementations.

I am writing a preprocessor and need to implement a simple
parser. It has to recognise identifiers. The characters allowed for
identifiers vary from language to language. I have the character set
configurable.

The question is which is the best way to implement the function
that returns whether an input character is in the set of identifier
characters. There are three ways that I want to test:
Stuff them in a String and access sequentially.
Stuff them in a String and access with a binary search.
Stuff them in a Treeset.
The outer parser code will be the same. The only difference will be
which character-checking method will be called.

I suppose I am going to end up doing cut-and-paste to make my
test program.

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On Wed, 22 Jun 2011 22:30:42 -0400, Joshua Cranmer

[snip]

Why are you having static methods (on the same class, I presume) for two
different ways of parsing instead of using separate parser classes?

I am not writing different parsers. I am writing different
methods for handling a small (but frequently called) part of the
parsing. I wish to test how fast each of these methods are.

Sincerely,

Gene Wirchenko

 

[Stefan Ram]

The question is which is the best way to implement the function
that returns whether an input character is in the set of identifier
characters. There are three ways that I want to test:
Stuff them in a String and access sequentially.
Stuff them in a String and access with a binary search.
Stuff them in a Treeset.

This would all only be needed, when it had to change at run time,
which is not the case here. So one uses source code, for example:

public static boolean isIdentifierCharacter( final int codePoint )
{ return codePoint >= 'a' && codePoint <= 'z'; }

. When the set of possible characters is small (ASCII), one can
use an array:

return isIdentifier[ codePoint ];

. For Unicode, one might use character properties, for example:

return java.lang.Character.isAlphabetic( codePoint );

 

[Gene Wirchenko]

This would all only be needed, when it had to change at run time,
which is not the case here. So one uses source code, for example:

Bad assumption. It is the case for what I am doing.

[snip]

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

On Thu, 23 Jun 2011 09:06:08 -0300, Arved Sandstrom

[snip]

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
Yes.

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).

Quite so. I am lazy. If I can do something reasonably well and
simply, so much the better. I do not get stupid about it though which
is why I wanted to benchmark. That led tomy question.

Sincerely,

Gene Wirchenko

 

[Joshua Cranmer]

Don't mind me - the last few years I've been questioning dogma. All of
it.

For what it's worth, I've spent the past few weeks starting to get
really tricky with python. I think I hit the apex when I realized I was
wanting a macro system in python, only shortly after writing functions
that returned functions. I think "good OO design" got thrown out the
window a while ago, although working in the same space as a bunch of
programming language interns is certainly going to mutate your sense of
good language design dogma.

 

[Fuschia, President-Elect of the Bright Purplish-Gr]

For what it's worth, I've spent the past few weeks starting to get
really tricky with python. I think I hit the apex when I realized I was
wanting a macro system in python, only shortly after writing functions
that returned functions. I think "good OO design" got thrown out the
window a while ago, although working in the same space as a bunch of
programming language interns is certainly going to mutate your sense of
good language design dogma.

Sounds like what you really want is a Lisp. Might I suggest Clojure?

 

[Joshua Cranmer]

Sounds like what you really want is a Lisp. Might I suggest Clojure?

Since it's not Java related, I don't want to dwell on it, but this
project has constraints which prohibit most languages. Python is pretty
much the only tenable language (legacy code being in python makes a big
difference, too ;-) ).

 

[Eric Sosman]

On Wed, 22 Jun 2011 22:09:05 -0400, Eric Sosman

[snip]

Y'know, Gene, you've been asking a spate of pretty elementary
questions. Maybe some time with a textbook or other documentation
would be helpful, or possibly relocation to c.l.j.help, which is
more beginner-oriented.

Yes, I know. I have been reading the on-line documentation, but
it is often hard to find out how to do something. I usually already
know the concept, but if it is called something different in Java, it
can be hard to find the documentation.

The standard Javadoc (if that's what you mean by "the on-line
documentation") is a reference, not a tutorial. It describes each
leaf in great detail, tells you a little about a few of the twigs,
but never mentions the branches, omits the tree, and ignores the
forest. Reading the Javadoc to learn Java is somewhat like reading
a dictionary to learn Finnish.

It seems to me that you're in need of a tutorial rather than a
reference, something that maps the forest and doesn't get bogged
down in the appearances of the individual stomata. There's one on
Oracle's site at <http://download.oracle.com/javase/tutorial/>; the
quality is uneven but you may find it useful. I'd especially
recommend the first four of the "Trails Covering the Basics."

What is the difference between the two newsgroups other than that
c.l.j.help seems fairly moribund?

In theory, c.l.j.help is supposed to help beginners learn their
way around Java, while c.l.j.programmer is supposed to be for more
experienced practitioners. That's the theory, and as you must know,
in theory there's no difference between theory and practice but in
practice there's no similarity.

 

[Eric Sosman]

On Wed, 22 Jun 2011 22:30:42 -0400, Joshua Cranmer

[snip]

Why are you having static methods (on the same class, I presume) for two
different ways of parsing instead of using separate parser classes?

I am not writing different parsers. I am writing different
methods for handling a small (but frequently called) part of the
parsing. I wish to test how fast each of these methods are.

As an aside: You're certainly aware that micro-benchmarks are
easy to concoct, but notoriously difficult to interpret. In Java,
concoction is equally easy but interpretation is *much* harder.
"Do X N times, do Y N times, measure the elapsed times" simply doesn't
work well in the face of just-in-time compilation, garbage collection,
the loading of ancillary classes, and so on.

 

[blmblm]

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.

Oh sure. That's why I included that footnote, the one you didn't
quote .... :

[*] Not that I've ever done anything like that. (Ha.)

I'm not above writing "ugly hack" code, and sometimes it might even be
the right thing to do, as in your "use case".

 

[Fuschia, President-Elect of the Bright Purplish-Gr]

Since it's not Java related, I don't want to dwell on it, but this
project has constraints which prohibit most languages. Python is pretty
much the only tenable language (legacy code being in python makes a big
difference, too ;-) ).

I find it hard to imagine project constraints that would allow Python,
but forbid Clojure. Python after all is slow, interpreted,
non-concurrent (what with the global interpreter lock), ... so pretty
much any technical consideration favors Clojure. Neither language is on
Apple's iOS approved list. Memory footprint? That would exclude JVM (and
..NET) languages at a stroke and might let Python squeak through.
Shellability? It's possible to make JVM languages shell-callable, but a
bit tricky since if you don't want to incur a JVM startup time per call
and a JVM memory overhead per simultaneously executing call you'll need
a nailgun server running or something similar.

My guess would be a combination of not liking JVM memory
consumption/startup times and interoperating with the legacy Python
code. (Though there is nailgun. And Jython.)

You might still want to consider a Lisp, but perhaps a more
commandline-friendly Lisp with a more compact footprint. Problem is I
bet it's quite a bit harder to get those to talk to Python than to get
Clojure to talk to Jython.

You may be stuck with Python for this one project with the legacy code.