refactoring problem

[Roedy Green]

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

 

[Arved Sandstrom]

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

 

[Arne Vajhøj]

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

 

[Joshua Cranmer]

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.

 

[Arne Vajhøj]

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

 

[Knute Johnson]

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

sure does look funky!

Arne

Perl does it.

 

[Arne Vajhøj]

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

 

[Roedy Green]

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

 

[Arne Vajhøj]

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

 

[Robert Klemme]

[...]

(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

 

[Arved Sandstrom]

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

 

[Arne Vajhøj]

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

 

[Lew]

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.

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.

 

[Silvio]

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

 

[Lew]

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.

 

[Silvio]

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.

 

[Lew]

...

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

 

[Lew]

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.

 

[Silvio]

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.


And yet you suggest another feature anyway.


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]

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.