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

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

refactoring problem

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

Contents

  refactoring problem Roedy Green <see_website@mindprod.com.invalid> - 2013-02-03 06:30 -0800
    Re: refactoring problem Martin Gregorie <martin@address-in-sig.invalid> - 2013-02-03 16:23 +0000
    Re: refactoring problem Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-03 12:27 -0400
      Re: refactoring problem Roedy Green <see_website@mindprod.com.invalid> - 2013-02-03 12:35 -0800
        Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 15:37 -0500
      Re: refactoring problem Leif Roar Moldskred <leifm@dimnakorr.com> - 2013-02-03 15:21 -0600
        Re: refactoring problem Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-03 17:38 -0400
        Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 16:46 -0500
      Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-03 14:36 -0800
    Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 11:34 -0500
    Re: refactoring problem Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-02-03 11:54 -0600
      Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 13:13 -0500
        Re: refactoring problem Knute Johnson <nospam@knutejohnson.com> - 2013-02-03 10:20 -0800
          Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-03 13:32 -0500
            Re: refactoring problem Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-03 10:50 -0800
              Re: refactoring problem Robert Klemme <shortcutter@googlemail.com> - 2013-02-03 21:38 +0100
              Re: refactoring problem "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2013-02-04 08:11 +0000
                Re: refactoring problem Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-02-04 03:56 -0800
        Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 13:21 +0100
          Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 12:35 -0800
            Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 22:15 +0100
              Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 13:49 -0800
                Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 23:51 +0100
              Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 13:53 -0800
                Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-04 23:48 +0100
                  Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-04 17:08 -0800
                    Re: refactoring problem Silvio <silvio@internet.com> - 2013-02-05 10:07 +0100
                      Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-05 13:13 -0800
                        Re: refactoring problem Jim Gibson <jimsgibson@gmail.com> - 2013-02-05 13:20 -0800
                          Re: refactoring problem Lew <lewbloch@gmail.com> - 2013-02-05 13:31 -0800
                            Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 21:42 -0500
              Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:33 -0500
            Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-04 18:32 -0500
              Re: refactoring problem Martin Gregorie <martin@address-in-sig.invalid> - 2013-02-05 01:50 +0000
            Re: refactoring problem Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-02-05 10:04 -0600
              Re: refactoring problem Gene Wirchenko <genew@telus.net> - 2013-02-05 10:38 -0800
                Re: refactoring problem Joshua Cranmer <Pidgeot18@verizon.invalid> - 2013-02-05 13:53 -0600
              Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-05 21:43 -0500
                Re: refactoring problem markspace <markspace@nospam.nospam> - 2013-02-05 19:15 -0800
                  Re: refactoring problem Arne Vajhøj <arne@vajhoej.dk> - 2013-02-08 23:58 -0500
    Re: refactoring problem Joerg Meier <joergmmeier@arcor.de> - 2013-02-05 11:09 +0100

Page 1 of 3  [1] 2 3  Next page →

#22043 — refactoring problem

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 

[toc] | [next] | [standalone]

#22045

On Sun, 03 Feb 2013 06:30:40 -0800, 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.
> 
>
> I could create a separate class just to hold the values.  This is
> tedious, but it may be the only way.
>
...which you can return from a method. I keep wondering whether I should 
use this approach but so far haven't used it.
 
> 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.
> 
Formally true, but not necessarily so in practice. You can return a class 
instance containing as many variables as you need to return.

You can also pass the constructor a reference to a mutable object which 
contains the variables you want to change. I use this quite a lot: its 
particularly useful for letting logically separate sets of methods access 
and manipulate a collection: each set of methods forms a class that's 
handed a reference to the collection.

Example: I've just finished dealing with a way of handling a collection 
of geographical points: Each point forms a Waypoint that contains 
coordinates and descriptive attributes together with the methods needed 
to access its (immutable) attributes. The collection forms a WaypointList 
class that holds a set of Waypoints as an ArrayList plus two TreeMaps 
that give keyed access to Waypoints and methods needed to add, remove and 
retrieve individual Waypoints. There is a requirement to read a waypoint 
file into the WaypointList and to write it out to a file: there are 
currently five externally defined waypoint file formats I need to deal 
with so there is a set of classes, one per file format, that each 
implement a load() and a save() method. 

In addition there will be three programs that carry out more complex 
operations on one or more WaypointLists: only one of these has been 
written so far.



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#22047

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

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

#22055

On Sun, 03 Feb 2013 12:27:59 -0400, Arved Sandstrom
<asandstrom2@eastlink.ca> 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 

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

#22056

On 2/3/2013 3:35 PM, Roedy Green wrote:
> On Sun, 03 Feb 2013 12:27:59 -0400, Arved Sandstrom
> <asandstrom2@eastlink.ca> 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

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

#22058

Arved Sandstrom <asandstrom2@eastlink.ca> 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 )

-- 
Leif Roar Moldskred

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

#22059

On 02/03/2013 05:21 PM, Leif Roar Moldskred wrote:
> Arved Sandstrom <asandstrom2@eastlink.ca> 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

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

#22060

On 2/3/2013 4:21 PM, Leif Roar Moldskred wrote:
> Arved Sandstrom <asandstrom2@eastlink.ca> 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

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

#22062

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

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

#22048

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

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

#22050

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

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

#22051

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

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

#22052

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

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

#22053

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

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

#22054

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.

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.

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.

Pete

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

#22057

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/

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

#22066

Peter Duniho wrote:

> I doubt we'll ever see the feature in C-based languages like Java and C#,

C# has anonymous tuples.  They had to add 'em to support Linq (or at least, 
that's my current understanding -- I'm neither an expert in the semantics nor 
the history of C#).

    -- chris 

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

#22073

On Mon, 4 Feb 2013 08:11:01 -0000, Chris Uppal wrote:

> Peter Duniho wrote:
> 
>> I doubt we'll ever see the feature in C-based languages like Java and C#,
> 
> C# has anonymous tuples.  They had to add 'em to support Linq (or at least, 
> that's my current understanding -- I'm neither an expert in the semantics nor 
> the history of C#).

.NET has a series of "Tuple" generic types, and indeed F# leverages these
types for its implementation of tuples.

But C# does not elevate the tuple to a language-supported feature, the way
that languages like Perl, F#, and others do. I.e. there's no special syntax
for declaring a tuple return type, nor of naming the individual members of
a tuple (in the .NET "Tuple" types, each element is simply named "Item1",
"Item2", etc.; C# does nothing to abstract this to user-declared names as
F# does).

As part of LINQ, C# does allow anonymous types, and in fact for these types
each individual member can have a user-declared name. But the user-declared
member name is really only useful in the method in which the type is
declared.

Instances of the anonymous type aren't returnable from methods in any
practical way. They can be passed to generic methods called from the method
in which they are declared (since a generic method doesn't actually care
what the members of the type parameter are), but they can't be returned
from the declaring method except as a plain "object". The caller of the
declaring type would have to access the individual components through
reflection.

Pete

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

#22074

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.

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

#22081

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

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web