static data for methods...

Discussion in 'Java' started by Andreas Leitgeb, Oct 9, 2013.

  1. 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.
     
    Andreas Leitgeb, Oct 9, 2013
    #1
    1. Advertising

  2. Andreas Leitgeb

    Stefan Ram Guest

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

    >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.
     
    Stefan Ram, Oct 9, 2013
    #2
    1. Advertising

  3. Andreas Leitgeb

    Guest

    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
     
    , Oct 9, 2013
    #3
  4. Stefan Ram <-berlin.de> wrote:
    > Andreas Leitgeb <> 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!
     
    Andreas Leitgeb, Oct 9, 2013
    #4
  5. <> 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!
     
    Andreas Leitgeb, Oct 9, 2013
    #5
  6. 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.
     
    Daniele Futtorovic, Oct 10, 2013
    #6
  7. Daniele Futtorovic <> 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.
     
    Andreas Leitgeb, Oct 10, 2013
    #7
  8. On 2013-10-10 15:13, Andreas Leitgeb allegedly wrote:
    > Daniele Futtorovic <> 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.
     
    Daniele Futtorovic, Oct 10, 2013
    #8
  9. Daniele Futtorovic <> wrote:
    > On 2013-10-10 15:13, Andreas Leitgeb allegedly wrote:
    >> Daniele Futtorovic <> 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.
     
    Andreas Leitgeb, Oct 10, 2013
    #9
  10. In article <>,
    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.
    >
    > 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.
     
    Kevin McMurtrie, Oct 12, 2013
    #10
  11. Kevin McMurtrie <> 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
     
    Andreas Leitgeb, Oct 18, 2013
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Neo
    Replies:
    1
    Views:
    524
    Scott Allen
    Jan 7, 2005
  2. SaravanaKumar
    Replies:
    6
    Views:
    9,408
    Tony Morris
    Oct 19, 2004
  3. Oliver Wong
    Replies:
    14
    Views:
    1,628
    Chris Uppal
    Jun 13, 2006
  4. lightning
    Replies:
    4
    Views:
    912
    Daniel Pitts
    Oct 30, 2008
  5. Kenneth McDonald
    Replies:
    5
    Views:
    324
    Kenneth McDonald
    Sep 26, 2008
Loading...

Share This Page