refactoring problem

Discussion in 'Java' started by Roedy Green, Feb 3, 2013.

  1. Roedy Green

    Roedy Green Guest

    Consider the following refactoring problem.

    There is a hunk of almost identical code that appears multiple times.
    It sets up 6 local variables.

    I would like to encapsulate it.

    The obvious way to handle it is to make all the variables instance.
    But they are ARE local. (I might be using threads)
    Further their declarations would be scattered to the winds.

    I could create a separate class just to hold the values. This is
    tedious, but it may be the only way.

    I think, why can methods have multiple inputs, but only one output? I
    have been thinking that for about 50 years, and it ,seems unlikely to
    change soon.

    Any other thoughts on the problem? Is this new lambda feature of any
    relevance?
    --
    Roedy Green Canadian Mind Products http://mindprod.com
    The first 90% of the code accounts for the first 90% of the development time.
    The remaining 10% of the code accounts for the other 90% of the development
    time.
    ~ Tom Cargill Ninety-ninety Law
    Roedy Green, Feb 3, 2013
    #1
    1. Advertising

  2. On 02/03/2013 10:30 AM, Roedy Green wrote:
    > Consider the following refactoring problem.
    >
    > There is a hunk of almost identical code that appears multiple times.
    > It sets up 6 local variables.
    >
    > I would like to encapsulate it.
    >
    > The obvious way to handle it is to make all the variables instance.
    > But they are ARE local. (I might be using threads)
    > Further their declarations would be scattered to the winds.
    >
    > I could create a separate class just to hold the values. This is
    > tedious, but it may be the only way.


    I think that's a decent way of handling this problem in Java.

    > I think, why can methods have multiple inputs, but only one output? I
    > have been thinking that for about 50 years, and it ,seems unlikely to
    > change soon.


    How exactly would you expect multiple outputs to work? If you've been
    thinking about this for about 50 years, then we're talking pretty much
    any programming language out there. Apart from the technique of defining
    a single object or struct to hold multiple return values, you have other
    languages that support returning lists or tuples. You do have languages
    (Scheme, for example) that return "true" multiple values from
    procedures, I don't see that their techniques have large advantages over
    tuples myself.

    And then of course there are things like generators, or for example,
    lazy evaluation of a map function over a list.

    What else would you have in mind?

    [ SNIP ]

    AHS
    Arved Sandstrom, Feb 3, 2013
    #2
    1. Advertising

  3. Roedy Green

    Arne Vajhøj Guest

    On 2/3/2013 9:30 AM, Roedy Green wrote:
    > Consider the following refactoring problem.
    >
    > There is a hunk of almost identical code that appears multiple times.
    > It sets up 6 local variables.
    >
    > I would like to encapsulate it.
    >
    > The obvious way to handle it is to make all the variables instance.
    > But they are ARE local. (I might be using threads)
    > Further their declarations would be scattered to the winds.
    >
    > I could create a separate class just to hold the values. This is
    > tedious, but it may be the only way.


    In/C++ you could use a macro, but in Java you will have to
    let a method return an object with multiple properties.

    > I think, why can methods have multiple inputs, but only one output? I
    > have been thinking that for about 50 years, and it ,seems unlikely to
    > change soon.


    In math a function return only one return value.

    That output could be a matrix, but it is still just one return value.

    > Any other thoughts on the problem? Is this new lambda feature of any
    > relevance?


    No.

    Arne
    Arne Vajhøj, Feb 3, 2013
    #3
  4. On 2/3/2013 8:30 AM, Roedy Green wrote:
    > I think, why can methods have multiple inputs, but only one output? I
    > have been thinking that for about 50 years, and it ,seems unlikely to
    > change soon.


    The short answer is that grammar makes N-ary arguments easy to express
    but N-ary returns difficult. Function calls evaluate to a value, so to
    implement N-ary returns, you have to effectively make tuples first-class
    values and treat multiple return values as tuple unpacking. In
    explicitly-typed languages like Java, this would make doing things like
    initializing multiple values of different types from a multiple-returned
    value syntactically annoying.

    Note that this issue doesn't exist in function calls, where the syntax
    of function calls makes it very easy to expand to more arguments by
    using an un(der)used "operator", i.e., the comma operator.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Feb 3, 2013
    #4
  5. On 2/3/2013 12:54 PM, Joshua Cranmer wrote:
    > On 2/3/2013 8:30 AM, Roedy Green wrote:
    >> I think, why can methods have multiple inputs, but only one output? I
    >> have been thinking that for about 50 years, and it ,seems unlikely to
    >> change soon.

    >
    > The short answer is that grammar makes N-ary arguments easy to express
    > but N-ary returns difficult. Function calls evaluate to a value, so to
    > implement N-ary returns, you have to effectively make tuples first-class
    > values and treat multiple return values as tuple unpacking. In
    > explicitly-typed languages like Java, this would make doing things like
    > initializing multiple values of different types from a multiple-returned
    > value syntactically annoying.


    (int a; double b; String c) = multiReturnValueMethod();

    sure does look funky!

    Arne
    Arne Vajhøj, Feb 3, 2013
    #5
  6. On 2/3/2013 10:13 AM, Arne Vajhøj wrote:
    > On 2/3/2013 12:54 PM, Joshua Cranmer wrote:
    >> On 2/3/2013 8:30 AM, Roedy Green wrote:
    >>> I think, why can methods have multiple inputs, but only one output? I
    >>> have been thinking that for about 50 years, and it ,seems unlikely to
    >>> change soon.

    >>
    >> The short answer is that grammar makes N-ary arguments easy to express
    >> but N-ary returns difficult. Function calls evaluate to a value, so to
    >> implement N-ary returns, you have to effectively make tuples first-class
    >> values and treat multiple return values as tuple unpacking. In
    >> explicitly-typed languages like Java, this would make doing things like
    >> initializing multiple values of different types from a multiple-returned
    >> value syntactically annoying.

    >
    > (int a; double b; String c) = multiReturnValueMethod();
    >
    > sure does look funky!
    >
    > Arne
    >
    >


    Perl does it.

    --

    Knute Johnson
    Knute Johnson, Feb 3, 2013
    #6
  7. On 2/3/2013 1:20 PM, Knute Johnson wrote:
    > On 2/3/2013 10:13 AM, Arne Vajhøj wrote:
    >> On 2/3/2013 12:54 PM, Joshua Cranmer wrote:
    >>> On 2/3/2013 8:30 AM, Roedy Green wrote:
    >>>> I think, why can methods have multiple inputs, but only one output? I
    >>>> have been thinking that for about 50 years, and it ,seems unlikely to
    >>>> change soon.
    >>>
    >>> The short answer is that grammar makes N-ary arguments easy to express
    >>> but N-ary returns difficult. Function calls evaluate to a value, so to
    >>> implement N-ary returns, you have to effectively make tuples first-class
    >>> values and treat multiple return values as tuple unpacking. In
    >>> explicitly-typed languages like Java, this would make doing things like
    >>> initializing multiple values of different types from a multiple-returned
    >>> value syntactically annoying.

    >>
    >> (int a; double b; String c) = multiReturnValueMethod();
    >>
    >> sure does look funky!

    >
    > Perl does it.


    How do I phrase this to avoid a language war.

    Hm.

    Perl is not designed to make it difficult to write funky code.

    :)

    Arne
    Arne Vajhøj, Feb 3, 2013
    #7
  8. Roedy Green

    Roedy Green Guest

    On Sun, 03 Feb 2013 12:27:59 -0400, Arved Sandstrom
    <> wrote, quoted or indirectly quoted someone
    who said :

    >How exactly would you expect multiple outputs to work?


    There is FORTH, but its solution could not be applied to Java.

    Inputs are values on the stack consumed by a methods. Outputs are
    values left on the stack. The number of each need not be fixed.

    Just as you can declare a parameter "final", you would be able to
    declare it "out". When you put the name of a variable in that slot of
    a parameter list, it would receive the value of the corresponding parm
    variable on exit. You could not put an expression in that slot, only
    left of = expressions. You might also allow inout variables (a weak
    version of Algol parm passing).
    --
    Roedy Green Canadian Mind Products http://mindprod.com
    The first 90% of the code accounts for the first 90% of the development time.
    The remaining 10% of the code accounts for the other 90% of the development
    time.
    ~ Tom Cargill Ninety-ninety Law
    Roedy Green, Feb 3, 2013
    #8
  9. Roedy Green

    Arne Vajhøj Guest

    On 2/3/2013 3:35 PM, Roedy Green wrote:
    > On Sun, 03 Feb 2013 12:27:59 -0400, Arved Sandstrom
    > <> wrote, quoted or indirectly quoted someone
    > who said :
    >
    >> How exactly would you expect multiple outputs to work?

    >
    > There is FORTH, but its solution could not be applied to Java.
    >
    > Inputs are values on the stack consumed by a methods. Outputs are
    > values left on the stack. The number of each need not be fixed.
    >
    > Just as you can declare a parameter "final", you would be able to
    > declare it "out". When you put the name of a variable in that slot of
    > a parameter list, it would receive the value of the corresponding parm
    > variable on exit. You could not put an expression in that slot, only
    > left of = expressions. You might also allow inout variables (a weak
    > version of Algol parm passing).


    Pass by reference could certainly be added to Java.

    That is a lot easier than multiple return values.

    Arne
    Arne Vajhøj, Feb 3, 2013
    #9
  10. On 03.02.2013 19:50, Peter Duniho wrote:
    > On Sun, 03 Feb 2013 13:32:08 -0500, Arne Vajhøj wrote:
    >
    >> [...]
    >>>> (int a; double b; String c) = multiReturnValueMethod();
    >>>>
    >>>> sure does look funky!
    >>>
    >>> Perl does it.

    >>
    >> How do I phrase this to avoid a language war.
    >>
    >> Hm.
    >>
    >> Perl is not designed to make it difficult to write funky code.


    Well put, Arne! ;-)

    > On the other hand, F# is designed that way and it supports tuple return
    > values as well.
    >
    > I doubt we'll ever see the feature in C-based languages like Java and C#,
    > but there are other languages that support it, and in at least some of
    > those examples, they do it gracefully.


    If you want a language that does it gracefully and runs on the JVM you
    can pick JRuby.

    > That said, it seems perfectly fine to me in Java to declare a container
    > type to allow multiple values to be returned. It's a common enough idiom
    > and works well.


    Absolutely!

    And if it was as easy as in (J)Ruby to declare a simple data container
    class it would even be convenient.

    # Ruby (without final though)
    FooBar = Struct.new :name, :length, :color

    // Java
    public struct FooBar {
    final String name;
    int length;
    Color color;
    }

    could generate

    public class FooBar {
    private final String name;
    private int length;
    private Color color;

    public(String name) {
    this.name = name;
    }

    public(String name, int length, Color color) {
    this.name = name;
    this.length = length;
    this.color = color;
    }

    public String getName() { return name; }
    // ...

    @Override
    public int hashCode() {...}

    @Override
    public boolean equals(Object o) {...}

    }

    Cheers

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Feb 3, 2013
    #10
  11. On 02/03/2013 05:21 PM, Leif Roar Moldskred wrote:
    > Arved Sandstrom <> wrote:
    >>
    >> What else would you have in mind?

    >
    > Well, I don't know what Roedy has in mind, but personally I think Ada
    > solved this elegantly with out parameters:
    >
    > procedure statistics( Data : in Height_Array; Max_Height, Min_Height :
    > out Integer; StdDev_Height : out Float )
    >

    Yeah, Roedy pointed this out. I knew I omitted something, over the years
    I've surely used half a dozen or more languages that had IN, OUT, INOUT
    type parameters, and that's not counting C pointers.

    I'm still partial to tuples.

    AHS
    Arved Sandstrom, Feb 3, 2013
    #11
  12. Roedy Green

    Arne Vajhøj Guest

    On 2/3/2013 4:21 PM, Leif Roar Moldskred wrote:
    > Arved Sandstrom <> wrote:
    >>
    >> What else would you have in mind?

    >
    > Well, I don't know what Roedy has in mind, but personally I think Ada
    > solved this elegantly with out parameters:
    >
    > procedure statistics( Data : in Height_Array; Max_Height, Min_Height :
    > out Integer; StdDev_Height : out Float )
    >


    Pascal, Basic, C# etc. also has that.

    Arne
    Arne Vajhøj, Feb 3, 2013
    #12
  13. Roedy Green

    Lew Guest

    Arved Sandstrom wrote:
    > Roedy Green wrote:
    >> Consider the following refactoring problem.
    >> There is a hunk of almost identical code that appears multiple times.
    >> It sets up 6 local variables.
    >> I would like to encapsulate it.

    >
    >> The obvious way to handle it is to make all the variables instance.
    >> But they are ARE local. (I might be using threads)
    >> Further their declarations would be scattered to the winds.

    >
    >> I could create a separate class just to hold the values. This is
    >> tedious, but it may be the only way.


    It might be tedious, but programming is a cost-benefit exercise.

    If you have six variables that are so tightly bound semantically that
    you consistently want to treat them as a unit, then you have a type.

    The right thing to do with a type in your programming model is to
    implement it as a type.

    > I think that's a decent way of handling this problem in Java.


    Or any OO-ish language.

    >> I think, why can methods have multiple inputs, but only one output? I
    >> have been thinking that for about 50 years, and it ,seems unlikely to
    >> change soon.

    >
    > How exactly would you expect multiple outputs to work? If you've been
    > thinking about this for about 50 years, then we're talking pretty much
    > any programming language out there. Apart from the technique of defining


    And a classic inquiry.

    > a single object or struct to hold multiple return values, you have other
    > languages that support returning lists or tuples. You do have languages


    A tuple is roughly equivalent to a struct or class with the same number
    of elements.

    If tuples or types do not require explicit declaration, then we have
    something like dynamic types.

    If we had a strongly-typed tuple language that was as rigid about
    declaration of tuples as Java is about types, we'd have comparable
    tedium.

    > (Scheme, for example) that return "true" multiple values from
    > procedures, I don't see that their techniques have large advantages over
    > tuples myself.
    >
    > And then of course there are things like generators, or for example,
    > lazy evaluation of a map function over a list.


    Maps are like the poor-man's dynamic type. They're lovely little data
    structures.

    > What else would you have in mind?


    Here's the thing. No language has it all, otherwise there'd be no programs
    left to write.

    So somewhere between that _reductio ad absurdum_ and the abacus each
    programming language has to choose a subset of tools, an axiomatic set
    if you will, that becomes core to the language. The rest you write yourself.

    You can do what you want in this case, and in this case it will be better
    program design anyway, by writing a type to express the relationship among
    those six things you represent as variables.

    Too bad for you that you find it tedious.

    Sometimes a great chef has to chop onions, though it make them cry.

    --
    Lew
    Lew, Feb 3, 2013
    #13
  14. Roedy Green

    Silvio Guest

    On 02/03/2013 07:13 PM, Arne Vajhøj wrote:
    > On 2/3/2013 12:54 PM, Joshua Cranmer wrote:
    >> On 2/3/2013 8:30 AM, Roedy Green wrote:
    >>> I think, why can methods have multiple inputs, but only one output? I
    >>> have been thinking that for about 50 years, and it ,seems unlikely to
    >>> change soon.

    >>
    >> The short answer is that grammar makes N-ary arguments easy to express
    >> but N-ary returns difficult. Function calls evaluate to a value, so to
    >> implement N-ary returns, you have to effectively make tuples first-class
    >> values and treat multiple return values as tuple unpacking. In
    >> explicitly-typed languages like Java, this would make doing things like
    >> initializing multiple values of different types from a multiple-returned
    >> value syntactically annoying.

    >
    > (int a; double b; String c) = multiReturnValueMethod();
    >
    > sure does look funky!
    >
    > Arne
    >
    >


    Scala does it with some minor syntactic sugar and makes it even a bit
    nicer using pattern matching.

    def multiReturnValueMethod : (Int,Double,String) = (0,3.11,"Foo bar")

    defines such a beast, with type inferencing allowing one to reduce it to

    def multiReturnValueMethod = (0,3.11,"Foo bar")

    Calling this without pattern matching would require

    val tuple3 = multiReturnValueMethod
    val i1 = tuple3._1
    val d2 = tuple3._2
    val s3 = tuple3._3

    And adding a little pattern matching makes this

    val (i1,d2,s3) = multiReturnValueMethod

    Note that the type (Int,Double,String) is syntactic sugar for
    Tuple3[Int,Double,String] and any expression (a,b,c) is desugared into
    new Tuple3(a,b,c) leaving it to type inferencing to figure out the type
    parameters. Nothing very dramatic that could not be added to the Java
    compiler if so desired.

    The pattern matching thing is somewhat more complex but that is also
    mostly about syntactic sugar.
    Silvio, Feb 4, 2013
    #14
  15. Roedy Green

    Lew Guest

    Silvio wrote:
    > parameters. Nothing very dramatic that could not be added to the Java
    > compiler if so desired.


    People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
    way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
    runtime generics and didn't get them, never mind Java already had another way to do the same thing.
    Then they wanted closures, and sorta got them, never mind Java already had another way to do the
    same thing. Now they want tuples, never mind that Java already has another way to do the same thing.

    "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.

    This is what happened to C++.

    Java will get all these things and the programming community will abandon the language,
    bitching that it's gotten too "heavy".

    The argument "it's just one little change" is a well-known lie. It's how customers eat up the
    profit margin for custom software. One thing and another and another and another and another
    and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
    people realize I just incurred Godwin's Law.

    --
    Lew
    Lew, Feb 4, 2013
    #15
  16. Roedy Green

    Silvio Guest

    On 02/04/2013 09:35 PM, Lew wrote:
    > Silvio wrote:
    >> parameters. Nothing very dramatic that could not be added to the Java
    >> compiler if so desired.

    >
    > People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
    > way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
    > runtime generics and didn't get them, never mind Java already had another way to do the same thing.
    > Then they wanted closures, and sorta got them, never mind Java already had another way to do the
    > same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
    >
    > "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
    >
    > This is what happened to C++.
    >
    > Java will get all these things and the programming community will abandon the language,
    > bitching that it's gotten too "heavy".
    >
    > The argument "it's just one little change" is a well-known lie. It's how customers eat up the
    > profit margin for custom software. One thing and another and another and another and another
    > and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
    > people realize I just incurred Godwin's Law.
    >


    I am not arguing things SHOULD be added to Java, just pointing out that
    they COULD be added. In fact, I have expressed multiple times that I
    think Java should be left alone (and should have been for quite some time).

    Java used to be a reasonably orthogonal minimalistic language. That made
    sense to me, just like languages like C++ or Scala which are
    feature-rich make sense to me.
    Features that have been added to Java in more recent versions are all
    over the place. Now it is a somewhat minimalistic language with a random
    and incoherent set of not so minimalistic features.

    But as always, tastes will differ.
    Silvio, Feb 4, 2013
    #16
  17. Roedy Green

    Lew Guest

    On Monday, February 4, 2013 1:15:55 PM UTC-8, Silvio wrote:
    > ...


    Please do not cc: your posts to my email address.
    Lew, Feb 4, 2013
    #17
  18. Roedy Green

    Lew Guest

    Silvio wrote:
    > Lew wrote:
    >> Silvio wrote:
    >>> parameters. Nothing very dramatic that could not be added to the Java
    >>> compiler if so desired.

    >
    >> People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
    >> way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
    >> runtime generics and didn't get them, never mind Java already had another way to do the same thing.
    >> Then they wanted closures, and sorta got them, never mind Java already had another way to do the
    >> same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
    >>
    >> "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
    >>
    >> This is what happened to C++.
    >>
    >> Java will get all these things and the programming community will abandon the language,
    >> bitching that it's gotten too "heavy".
    >>
    >> The argument "it's just one little change" is a well-known lie. It's how customers eat up the
    >> profit margin for custom software. One thing and another and another and another and another
    >> and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
    >> people realize I just incurred Godwin's Law.

    >
    > I am not arguing things SHOULD be added to Java, just pointing out that
    > they COULD be added.


    That was perfectly clear, and the context to which I spoke.

    Unless you are also pitching that maybe it SHOULD be part of Java, stating that it
    COULD be added to Java is a noop. Anything COULD be added to Java. I'm in favor of an
    ENVIRONMENT section myself.

    Simply stating that something COULD be added to Java is pretty much an empty statement.

    > In fact, I have expressed multiple times that I
    > think Java should be left alone (and should have been for quite some time).


    And yet you suggest another feature anyway.

    > Java used to be a reasonably orthogonal minimalistic language. That made
    > sense to me, just like languages like C++ or Scala which are
    > feature-rich make sense to me.
    >
    > Features that have been added to Java in more recent versions are all
    > over the place. Now it is a somewhat minimalistic language with a random
    > and incoherent set of not so minimalistic features.
    >
    > But as always, tastes will differ.


    Well, the decisions as to what actually makes it into Java or not are not made on the basis
    of taste.

    Which is arguably the worst of seemingly plausible criteria for inclusion.

    --
    Lew
    Lew, Feb 4, 2013
    #18
  19. Roedy Green

    Silvio Guest

    On 02/04/2013 10:53 PM, Lew wrote:
    > Silvio wrote:
    >> Lew wrote:
    >>> Silvio wrote:
    >>>> parameters. Nothing very dramatic that could not be added to the Java
    >>>> compiler if so desired.

    >>
    >>> People are never satisfied. They wanted delegates, didn't get them, never mind Java got another
    >>> way to do the same thing. Then they wanted generics, and sorta got them. Then they wanted
    >>> runtime generics and didn't get them, never mind Java already had another way to do the same thing.
    >>> Then they wanted closures, and sorta got them, never mind Java already had another way to do the
    >>> same thing. Now they want tuples, never mind that Java already has another way to do the same thing.
    >>>
    >>> "Oh, it's just one more little thing!" they always exclaim. For a thousand little things.
    >>>
    >>> This is what happened to C++.
    >>>
    >>> Java will get all these things and the programming community will abandon the language,
    >>> bitching that it's gotten too "heavy".
    >>>
    >>> The argument "it's just one little change" is a well-known lie. It's how customers eat up the
    >>> profit margin for custom software. One thing and another and another and another and another
    >>> and the game is how long you can say, "I'm only just going to take Poland, nothing else" before
    >>> people realize I just incurred Godwin's Law.

    >>
    >> I am not arguing things SHOULD be added to Java, just pointing out that
    >> they COULD be added.

    >
    > That was perfectly clear, and the context to which I spoke.
    >
    > Unless you are also pitching that maybe it SHOULD be part of Java, stating that it
    > COULD be added to Java is a noop. Anything COULD be added to Java. I'm in favor of an
    > ENVIRONMENT section myself.
    >
    > Simply stating that something COULD be added to Java is pretty much an empty statement.
    >
    >> In fact, I have expressed multiple times that I
    >> think Java should be left alone (and should have been for quite some time).

    >
    > And yet you suggest another feature anyway.
    >
    >> Java used to be a reasonably orthogonal minimalistic language. That made
    >> sense to me, just like languages like C++ or Scala which are
    >> feature-rich make sense to me.
    >>
    >> Features that have been added to Java in more recent versions are all
    >> over the place. Now it is a somewhat minimalistic language with a random
    >> and incoherent set of not so minimalistic features.
    >>
    >> But as always, tastes will differ.

    >
    > Well, the decisions as to what actually makes it into Java or not are not made on the basis
    > of taste.
    >
    > Which is arguably the worst of seemingly plausible criteria for inclusion.
    >


    Well, what where those decisions based on then? Something else than the
    personal taste of a small group of influential insiders?
    Silvio, Feb 4, 2013
    #19
  20. Roedy Green

    Silvio Guest

    On 02/04/2013 10:49 PM, Lew wrote:
    > On Monday, February 4, 2013 1:15:55 PM UTC-8, Silvio wrote:
    >> ...

    >
    > Please do not cc: your posts to my email address.
    >


    Actually it was not a CC. Thunderbird has renamed the "Reply to group"
    button to "Follow up". Since then I mistakenly keep using the "Reply"
    button instead and then use the other one as soon as I realize my
    mistake. Sorry about that.
    Silvio, Feb 4, 2013
    #20
    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. Refactorit

    come learn all about refactoring

    Refactorit, Feb 22, 2004, in forum: Java
    Replies:
    0
    Views:
    342
    Refactorit
    Feb 22, 2004
  2. Sebastian Jekutsch

    Survey on refactoring activities using IDEs

    Sebastian Jekutsch, Jun 8, 2004, in forum: Java
    Replies:
    5
    Views:
    466
  3. Christian Bongiorno

    Odd Multi-thread behavior when refactoring

    Christian Bongiorno, Jun 21, 2004, in forum: Java
    Replies:
    1
    Views:
    385
    Thomas Weidenfeller
    Jun 22, 2004
  4. Anan H. Samiti
    Replies:
    33
    Views:
    5,474
    Roedy Green
    Jul 30, 2004
  5. Roedy Green

    a class refactoring problem.

    Roedy Green, May 2, 2009, in forum: Java
    Replies:
    3
    Views:
    338
    Mark Space
    May 3, 2009
Loading...

Share This Page