Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #26246 > unrolled thread

static data for methods...

Back to article view | Back to comp.lang.java.programmer

Contents

  static data for methods... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-09 14:18 +0000
    Re: static data for methods... taqmcg@gmail.com - 2013-10-09 07:49 -0700
      Re: static data for methods... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-09 15:42 +0000
    Re: static data for methods... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-09 15:29 +0000
    Re: static data for methods... Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-10-10 14:44 +0200
      Re: static data for methods... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-10 13:13 +0000
        Re: static data for methods... Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2013-10-10 15:44 +0200
          Re: static data for methods... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-10 17:26 +0000
    Re: static data for methods... Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2013-10-11 22:03 -0700
      Re: static data for methods... Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2013-10-18 15:31 +0000

#26246 — static data for methods...

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.

[toc] | [next] | [standalone]

#26249

On Wednesday, October 9, 2013 10:18:43 AM UTC-4, Andreas Leitgeb wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#26251

taqmcg@gmail.com <taqmcg@gmail.com> wrote:
> On Wednesday, October 9, 2013 10:18:43 AM UTC-4, Andreas Leitgeb wrote:
>> 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.

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!

[toc] | [prev] | [next] | [standalone]

#26250

Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> writes:
>> 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.

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

>> However, I need the static fields lexically separated for the
>> methods.
>   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!

[toc] | [prev] | [next] | [standalone]

#26282

On 2013-10-09 16:18, Andreas Leitgeb allegedly wrote:
> 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?

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#26283

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
> On 2013-10-09 16:18, Andreas Leitgeb allegedly wrote:
>> 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.
> 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.

[toc] | [prev] | [next] | [standalone]

#26286

On 2013-10-10 15:13, Andreas Leitgeb allegedly wrote:
> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
>> On 2013-10-09 16:18, Andreas Leitgeb allegedly wrote:
>>> 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.
>> 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.

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

-- 
DF.

[toc] | [prev] | [next] | [standalone]

#26294

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
> On 2013-10-10 15:13, Andreas Leitgeb allegedly wrote:
>> Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:
>>> 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.
> *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.

[toc] | [prev] | [next] | [standalone]

#26311

In article <slrnl5ape4.mol.avl@gamma.logic.tuwien.ac.at>,
 Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> wrote:

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

[toc] | [prev] | [next] | [standalone]

#26373

Kevin McMurtrie <mcmurtrie@pixelmemory.us> wrote:
> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web