«

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

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

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

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

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

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

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

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

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

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/