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

"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

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

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

> 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

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

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

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

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

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

Wording improvements for String.indexOf, String.lastIndexOf

Hi Alan, Xueming, I'd like you to do a code review. http://cr.openjdk.java.net/~martin/webrevs/openjdk7/lastIndexOf2/ A colleague suggested wording improvements for String.indexOf and String.lastIndexOf At least, this makes the javadoc less gratuitously inconsistent. Since I'm already coinciden

Re: A List implementation backed by multiple small arrays rather than the traditional single large array.

What am I missing here? In "Resizable arrays in optimal time and space" the authors define their data structure with the following property: (1) "When superblock SB_k is fully allocated, it consists of 2^(floor(k/2)) data blocks, each of size 2^(ceil(k/2))." Since the superblock is zero-based i

Re: A List implementation backed by multiple small arrays rather than the traditional single large array.

I realize that 2 * (2^(k/2) - 1) only works for even numbered superblocks, the odd numbered superblocks need an additional term added (the number of data blocks in SB_[k-1]) to jive with my interpretation; anyhow, I also came across an alternative characterization of superblock in the paper which s

Re: A List implementation backed by multiple small arrays rather than the traditional single large array.

I'm almost convinced now that the paper is incorrect. The code below gives me the appropriate index into the index array and the offset into the data block. That being said, remember when I mentioned that this will include a bit more work to access an element than a simple bit shift and a bit mas