Re: java.util.Pair

t;John Rose" >>> À: "Rémi Forax" >>> Cc: "joe darcy" , "core-libs-dev" >>> >>> Envoyé: Jeudi 13 Juillet 2017 23:05:14 >>> Objet: Re: java.util.Pair >>> On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@un

Re: java.util.Pair

v.fr wrote: > >> De: "John Rose" >>> À: "Rémi Forax" >>> Cc: "joe darcy" , "core-libs-dev" >>> >>> Envoyé: Jeudi 13 Juillet 2017 23:05:14 >>> Objet: Re: java.util.Pair >>> On Jul 13, 2017, at 1:3

Re: java.util.Pair

"John Rose" À: "Rémi Forax" Cc: "joe darcy" , "core-libs-dev" Envoyé: Jeudi 13 Juillet 2017 23:05:14 Objet: Re: java.util.Pair On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr | fo...@univ-mlv.fr ] > wrote: Tuples are like an array

Re: java.util.Pair

> De: "John Rose" > À: "Rémi Forax" > Cc: "joe darcy" , "core-libs-dev" > > Envoyé: Jeudi 13 Juillet 2017 23:05:14 > Objet: Re: java.util.Pair > On Jul 13, 2017, at 1:39 PM, Remi Forax < [ mailto:fo...@univ-mlv.fr | > fo...

Re: java.util.Pair

On Jul 13, 2017, at 1:39 PM, Remi Forax wrote: > > Tuples are like an array of value types parameterized by a constant integer The homogeneous case is pretty simple; most of what you need is to allow a generic type to be parameterized by an integer. C++ templates have had that for a long time.

Re: java.util.Pair

"Hohensee, Paul" , core-libs-dev@openjdk.java.net > Envoyé: Jeudi 13 Juillet 2017 19:22:19 > Objet: Re: java.util.Pair > Hi Paul, > > See the discussion in thread: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html > http://mail.o

Re: java.util.Pair

On Jul 13, 2017, at 10:29 AM, Maurizio Cimadamore wrote: > > Maybe automatic refactoring to Map.Entry ? With the new static method added > in 9, creating one is also very fluent (but I > know that Entry doesn't convey same meaning as Pair in method > signatures/fields) The JavaFX Pair Paul is

Re: java.util.Pair

Similarly, I've used https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleEntry.html and https://docs.oracle.com/javase/8/docs/api/java/util/AbstractMap.SimpleImmutableEntry.html in these circumstances. On Thu, Jul 13, 2017 at 1:29 PM Maurizio Cimadamore < maurizio.cimadam...@orac

Re: java.util.Pair

Hi All, FYI: We added a couple of classes in Apache Commons Lang to deal with pairs and triples. This is definitely for the pragmatic programmer... https://commons.apache.org/proper/commons-lang/javadocs/api-release/org/apache/commons/lang3/tuple/Pair.html https://commons.apache.org/proper/common

Re: java.util.Pair

Thanks for the immediate response. Having read the thread, I understand the argument against including Pair in the JDK and personally agree with the sw engineering argument. But, it got into javafx.util somehow and is now effectively part of the JDK anyway, so that ship has sailed. Thus, it see

Re: java.util.Pair

That’s a possibility. We could recommend that as an alternative. Thanks, Paul On 7/13/17, 10:29 AM, "Maurizio Cimadamore" wrote: Maybe automatic refactoring to Map.Entry ? With the new static method added in 9, creating one is also very fluent (but I know that Entry doesn't conv

Re: java.util.Pair

Maybe automatic refactoring to Map.Entry ? With the new static method added in 9, creating one is also very fluent (but I know that Entry doesn't convey same meaning as Pair in method signatures/fields) http://download.java.net/java/jdk9/docs/api/java/util/Map.html#entry-K-V- Cheers Maurizio

Re: java.util.Pair

Hi Paul, See the discussion in thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-March/003973.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-April/thread.html In short, no current plans to add java.util.Pair. -Joe On 7/13/2017 10:07 AM, Hohensee, Paul wrote:

Re: java.util.Pair

On 30/03/2010 09:08, Weijun Wang wrote: > I know such a simple thing can be made very complex and everyone might > want to add a new method into it. How about we just make it most > primitive? Simply an immutable and Serializable class, two final > fields, one constructor, two getters (?), and no

Re: java.util.Pair

I think an object oriented language like Java should not contain a class where there are so many different candidate names for its fields. It's a code smell for improper abstraction. There are lots of classes that are structurally similar but they are defined in different classes as they are abstra

Re: java.util.Pair

Please don't add this. I have my own tuple parametric class. In fact it is easy to do. http://code.google.com/p/bookjar-utils/source/browse/BookJar-utils/src/util/Tuples.java However i never use it anymore. It is easy to do & use, but really stupid since the names (first, second, third...) are so

Re: java.util.Pair

On Wed, Mar 31, 2010 at 10:20 AM, Kevin Bourrillion wrote: > With all due respect, I rest my case. :-) > > (Meaning: since you chose such a hypothetical future situation as an > illustration, it suggests that indeed no actual bugs are being prevented > here in the real world.) > > We have to recog

Re: java.util.Pair

On Wed, Mar 31, 2010 at 10:04 AM, Rémi Forax wrote: > (And even if it were right in theory (which I don't think it is), weren't > warnings supposed to be things that would warn you about possible *bugs*?) > > possible bug: > the semantics of instanceof Foo and instanceof Foo is different if > ge

Re: java.util.Pair

Le 31/03/2010 17:34, Kevin Bourrillion a écrit : On Wed, Mar 31, 2010 at 12:31 AM, Rémi Forax > wrote: In equals, instanceof Pair should be instanceof Pair. Pair is a raw type. Tangent: there are those of us who believe javac is quite mistaken to issue a warn

Re: java.util.Pair

Just to add my voice to the chorus, I think adding pair is seductive but ill-considered. Based on our experience at Google, I believe it makes a bad situation worse. I do believe that Kevin's idea is worth of exploration: in essence trying to encapsulate all of the knowledge in Chapter 3 of Effec

Re: java.util.Pair

> Date: Wed, 31 Mar 2010 09:14:59 -0700 > From: Kevin Bourrillion > ... > > The problem is that classes like Pair simply go that much further to indulge > the desire to never have to create any actual types of our own. When we're > forced to create our own types, we begin to model our data more

Re: java.util.Pair

On Wed, Mar 31, 2010 at 8:36 AM, Bob Lee wrote: Please don't add Pair. It should never be used in APIs. Adding it to > java.util will enable and even encourage its use in APIs. The damage done to > future Java APIs will be far worse than a few duplicate copies of Pair (I > don't even see that man

Re: java.util.Pair

On Tue, Mar 30, 2010 at 4:34 PM, wrote: > While I have sympathy with that conclusion, there is the > side-effect of littering many APIs with the flotsam of lots of different > classes named "Pair." My inclination would be to produce one adequate > Pair class in the JDK to prevent the proliferati

Re: java.util.Pair

On Wed, Mar 31, 2010 at 12:31 AM, Rémi Forax wrote: In equals, instanceof Pair should be instanceof Pair. > Pair is a raw type. > Tangent: there are those of us who believe javac is quite mistaken to issue a warning on 'instanceof Pair'. (And even if it were right in theory (which I don't think

Re: java.util.Pair

"implements Serializable"? -Max On Mar 31, 2010, at 7:34 AM, joe.da...@oracle.com wrote: > > > On 3/30/2010 10:54 AM, Kevin Bourrillion wrote: >> Pair is only a partial, flawed solution to a special case (n=2) of a very >> significant problem: the disproportionate complexity of creating value

Re: java.util.Pair

Le 31/03/2010 01:34, joe.da...@oracle.com a écrit : On 3/30/2010 10:54 AM, Kevin Bourrillion wrote: Pair is only a partial, flawed solution to a special case (n=2) of a very significant problem: the disproportionate complexity of creating value types in Java. I support addressing the underly

Re: java.util.Pair

On 3/30/2010 10:54 AM, Kevin Bourrillion wrote: Pair is only a partial, flawed solution to a special case (n=2) of a very significant problem: the disproportionate complexity of creating value types in Java. I support addressing the underlying problem in Java 8, and not littering the API wit

RE: java.util.Pair

re is there a corner case that I'm not seeing or is the main reservation the extra method calls and creation of some well behaved garbage? Jason > Date: Tue, 30 Mar 2010 17:01:57 -0400 > Subject: Re: java.util.Pair > From: scolebou...@joda.org > To: core-libs-dev@openjdk.java

Re: java.util.Pair

(I´m writing from a slow connection in a national park in Chile) I meant a decortator for an iterator that wraps the original making it immutable. Stephen On 30 March 2010 16:55, Martin Buchholz wrote: > On Tue, Mar 30, 2010 at 13:39, Stephen Colebourne > wrote: >> While I support Kevin´s sum

Re: java.util.Pair

On Tue, Mar 30, 2010 at 13:39, Stephen Colebourne wrote: > While I support Kevin´s summary, having a public implementation of > Map.Entry in java.util would be very useful. (Along with making other > private classes public - unmodifiable iterator is one IIRC) ./AbstractMap.java:569:public sta

Re: java.util.Pair

While I support Kevin´s summary, having a public implementation of Map.Entry in java.util would be very useful. (Along with making other private classes public - unmodifiable iterator is one IIRC) Stephen On 30 March 2010 13:54, Kevin Bourrillion wrote: > Pair is only a partial, flawed solution t

Re: java.util.Pair

Pair is only a partial, flawed solution to a special case (n=2) of a very significant problem: the disproportionate complexity of creating value types in Java. I support addressing the underlying problem in Java 8, and not littering the API with dead-end solutions like Pair. On Tue, Mar 30, 201

Re: java.util.Pair

Hi! Do you mean, it would be good to have a "standard" implementing class of the interface Map.Entry ? This does exist: AbstractMap.SimpleEntry. Well, of course both the interface and the class are somewhat 'hidden', but nevertheless, they do exist. 30.03.10, 16:08, "Weijun Wang" : > Hi All

Re: java.util.Pair

Weijun Wang wrote: Hi All There are multiple CRs asking for a java.util.Pair class: 4983155 6229146 4947273 I know such a simple thing can be made very complex and everyone might want to add a new method into it. How about we just make it most primitive? Simply an immutable and Seri