static data for methods...

[Andreas Leitgeb]

I'm aware that in Java, methods cannot have static data within
them. The usual "workaround" is to place static data for a
method in static fields of the class. However, I need the
static fields lexically separated for the methods.

My first thought was to write a static class named after the
method, then start the method like this:

static class static_fuBar { static int foo; static int bar; ... }
public static void fuBar(...) {
import static static_fuBar.*;
// now use foo and bar by their bare names ...
}

That of course doesn't work, either, because Java is very
restrictive about where "import static" can be used. (I added
it merely to illustrate what I'd like to arrive at.) Is there
some other trick?


PS: besides fuBar, I'll also have a couple further methods with
each's own set of effectively-static canonically-named fields, so
making foo&bar just static fields of the main class is not an option.
also renaming each foo and bar to <methodname>_foo and <methodname>_bar
isn't satisfying.

PPS: If this path of thought is really a dead end, then I'll do
the backtracking, myself, so no need asking for the broader picture.

 

[Stefan Ram]

I'm aware that in Java, methods cannot have static data within
them.

You can encapsulate both in a class that consists just of
the static data and this single method. Actually, that's
how classes came up in Simula IIRC.

However, I need the static fields lexically separated for the
methods.

What is this lexical separation? I do not know this term.

My first thought was to write a static class named after the
method, then start the method like this:
static class static_fuBar { static int foo; static int bar; ... }

Your class name contains the letter »f«, which I do not
recommend, since there are indecent words in English that
start with this letter. (Below, I will explain a limitation
of this general rule.) This applies even more when this
letter then is followed by a »u«.

I would write this as:

static class epsilon { static int alpha; static int beta; ... }
¯¯¯¯¯¯¯ ¯¯¯¯¯ ¯¯¯¯

That also has more of what is known as the »academic tone«,
thus looks more professional.

That of course doesn't work, either, because Java is very
restrictive about where "import static" can be used. (I added
it merely to illustrate what I'd like to arrive at.) Is there
some other trick?

So, what's wrong with

final class counter
{ static int field = 0;
static int next(){ return field++; }}

?

Ok, the above also contains words that do start with »f«,
but since these are real and decent English words, they do
not hint on indecent words. What you wrote was not a real
English word. One can use »f« when it is a part of
well-known decent English words.

 

[taqmcg]

I'm aware that in Java, methods cannot have static data within
them. The usual "workaround" is to place static data for a
method in static fields of the class. However, I need the
static fields lexically separated for the methods.

If you really want a separate name space for each function you could use the name spacing provided in nested classes.

E.g.,

class Primary {

static class Method1 {
static char someVar;
... static definitions for method1
}

static class Method2 {
... static definitions for method2
}

void method1() {
char xx = Method1.someVar;
...
}

void method2() {
...
}
}

where the association of the nested class Method1 with the method method would be a local convention. This gives you a reasonably safe name space.

It doesn't allow you to access the static variables without qualification though.

If you just don't want to have to worry about prefixing different method names on each usage of a variable you could try something like:

...
void method1() {
final Method1 statics = null;
...
localVar = statics.someVar;
...
}
...
where you define a variable of the appropriate type. Then in methods that use this convention 'statics' could be used uniformly to reference each method's static data.

Not sure whether this addresses what you want, but it does only mild violence to standard usage. While you'd be using using a variable to reference static's the name 'statics' should limit any confusion that might cause -- given that this would be a general convention within a block of code.

Good luck,
Tom McGlynn

 

[Andreas Leitgeb]

You can encapsulate both in a class that consists just of
the static data and this single method. Actually, that's
how classes came up in Simula IIRC.

Probably that's be the optimum of what's available. Thanks!

What is this lexical separation? I do not know this term.

It's that two methods fuBar() and snaFu() both might need their
own static "foo" field (and both want it by that exact name, because
the real name is really something meaningful, not "foo") and that
fuBar()'s "foo" must be a separate thing from e.g. snaFu()'s "foo".
Btw., that's perfectly well handled with your suggestion.

Your class name contains the letter »f«, ...

I thought it would be obvious, that code samples in newsgroups using
names from the list: foo, bar, baz, snafu, fubar
are typically not taken exactly from real code, but placeholders for
variable names that contain domain-language. (I'm not ruling out that
people might name variables like that even in real code, but it's just
not the one thing to assume generally.)

I assure you, that the methods and variables in my actual code
DO include non-english words starting with "f", but neither from
the above list, nor that "f"-word that foo and fubar were derived
from, nor other derivations of that word.

So, what's wrong with
final class counter
{ static int field = 0;
static int next(){ return field++; }}

Nothing's wrong. It's the suggestion you made at the top
of your post and I think I'll actually take that approach.

Btw., I'll make class "counter" static and also create a trivial
wrapper-method for "next()" in the toplevel class, so the method
can later be called from other (similarly wrapped) methods of that
toplevel class. (I'm also expecting that the extra call-level will
be a piece of cake for the JIT to optimize away later.)

Thanks a lot!

 

[Andreas Leitgeb]

If you really want a separate name space for each function you
could use the name spacing provided in nested classes.

Stefan Ram already scored a better(*) hit:
(*): according to my (OP's) subjective preferences

Stefan's approach (slightly adapted):

class Primary {
static class Method1 {
static char someVar; ...
void method1() {
char xx = someVar; ... // no qualification needed
}
}
void method1() { Method1.method(); } // simple wrapper @ toplevel

...
}

Thanks, anyway!

 

[Daniele Futtorovic]

I'm aware that in Java, methods cannot have static data within
them. The usual "workaround" is to place static data for a
method in static fields of the class. However, I need the
static fields lexically separated for the methods.

My first thought was to write a static class named after the
method, then start the method like this:

static class static_fuBar { static int foo; static int bar; ... }
public static void fuBar(...) {
import static static_fuBar.*;
// now use foo and bar by their bare names ...
}

That of course doesn't work, either, because Java is very
restrictive about where "import static" can be used. (I added
it merely to illustrate what I'd like to arrive at.) Is there
some other trick?


PS: besides fuBar, I'll also have a couple further methods with
each's own set of effectively-static canonically-named fields, so
making foo&bar just static fields of the main class is not an option.
also renaming each foo and bar to <methodname>_foo and <methodname>_bar
isn't satisfying.

PPS: If this path of thought is really a dead end, then I'll do
the backtracking, myself, so no need asking for the broader picture.

Quick Q: is this you trying to be economical while doing a refactoring,
or you designing a FUBAR'd mess?

 

[Andreas Leitgeb]

Quick Q: is this you trying to be economical while doing a refactoring,
or you designing a FUBAR'd mess?

The former is close enough. The latter is its inevitable result.

PS: I expected this (entirely justified) question would come up.

 

[Daniele Futtorovic]

The former is close enough. The latter is its inevitable result.

PS: I expected this (entirely justified) question would come up.

*Shudder*. Anyway, for my two cents, I'd consider two avenues: a static
map where the methods pick their fields (perhaps IdentityHashMap) or, if
the performance hit is a concern, perhaps a custom annotation and an
annotation parser that would inject the fields into the source code
pre-compilation (I'm pretty sure that's possible, although I don't
remember how exactly).

 

[Andreas Leitgeb]

*Shudder*

Indeed - although the pseudo-local-statics by far aren't the worst.
(At least no longer, thanks to Stefan's suggestion.)

<rant>
Some parts will be ugly as hell primarily for Java's lack of
- operator overloading,
- typedef (give some (e.g. generic) type a simple local name),
- multi-inheritence (for classes) or static methods in interfaces.
- "import static" into local scopes.
- a pre-processor (duck & run
</rant>

I'm not even trying to advocate them for Java (no chance, anyway),
but these things simply are, what makes the resulting Java code
highly repetitive, abundantly verbose, roundabout and ugly.

Anyway, for my two cents, I'd consider two avenues: a static
map where the methods pick their fields (perhaps IdentityHashMap)

Actually, I do appreciate the compiler being able to check
variable and method names at compiletime.

or, if the performance hit is a concern, perhaps a custom annotation and an
annotation parser that would inject the fields into the source code
pre-compilation (I'm pretty sure that's possible, although I don't
remember how exactly).

Annotations (well, beyond @Override and @SuppressWarnings) actually
make me shudder even more. No idea, what I'm really missing with that.
It's not the defining or applying them, but the part, where they'd
actually have to trigger/do modifications at/on/to the bytecode.

 

[Kevin McMurtrie]

I'm aware that in Java, methods cannot have static data within
them. The usual "workaround" is to place static data for a
method in static fields of the class. However, I need the
static fields lexically separated for the methods.

My first thought was to write a static class named after the
method, then start the method like this:

static class static_fuBar { static int foo; static int bar; ... }
public static void fuBar(...) {
import static static_fuBar.*;
// now use foo and bar by their bare names ...
}

That of course doesn't work, either, because Java is very
restrictive about where "import static" can be used. (I added
it merely to illustrate what I'd like to arrive at.) Is there
some other trick?


PS: besides fuBar, I'll also have a couple further methods with
each's own set of effectively-static canonically-named fields, so
making foo&bar just static fields of the main class is not an option.
also renaming each foo and bar to <methodname>_foo and <methodname>_bar
isn't satisfying.

PPS: If this path of thought is really a dead end, then I'll do
the backtracking, myself, so no need asking for the broader picture.

ugh. I've spent many weeks of my life rewriting ancient C code having
such designs because it crashes and glitches like mad in a modern
runtime environment.

It's not a feature in Java because the nature of this design creates
code that is impossible to make thread-safe and reusable. Mutable
static fields even at the top-level are generally a bad idea. The only
time I'd consider them completely OK is when they represent a single
resource in the universe.

A better solution is to use normal fields and keep re-using the instance
of the class containing them.

 

[Andreas Leitgeb]

ugh. I've spent many weeks of my life rewriting ancient C code having
such designs because it crashes and glitches like mad in a modern
runtime environment.

I'm glad that this newsgroup won't let one do goofy stuff without
at least making dead sure that the person is aware of it...

My task is like in Franz Kafka's "Metamorphosis": The physical transition
will be "instantly" (well, at least once the machinery for "turning human
into vermin" is completed), whereas the "cultural" transition of the subject
will take its time...

To clarify: my task is really a metamorphosis from "vermin" to "human", but
Franz Kafka just wouldn't listen to my suggestion about changing his book.
(I visited him with my time machine, just for the sake of trying to simplify
this post, but invain - after I came back to my time his book only had that
one typo corrected but no change to the plot.)

PS: http://ebooks.adelaide.edu.au/k/kafka/franz/metamorphosis/chapter1.html