On Dec 24 2010, at 17:32 , Ulf Zibis wrote:
Trying to correct white space ...
Am 23.12.2010 23:59, schrieb Paul Benedict:
Ulf, a previous email by Remi said only to invoke size() if the collection
is a Set.
Thanks I missed that.
My guess was, that size() should be always faster than
On Dec 23 2010, at 13:24 , Ulf Zibis wrote:
Am 23.12.2010 20:46, schrieb Mike Duigou:
I have updated the webrev with the javadoc changes (identical to below) and
Ulf's suggested code changes:
http://cr.openjdk.java.net/~mduigou/6728865.3/webrev/
Thanks, I could convince you mostly.
Am 03.01.2011 21:16, schrieb Mike Duigou:
On Dec 24 2010, at 17:32 , Ulf Zibis wrote:
Am 23.12.2010 23:59, schrieb Paul Benedict:
Ulf, a previous email by Remi said only to invoke size() if the collection is a
Set.
Thanks I missed that.
My guess was, that size() should be always faster than
Am 03.01.2011 23:15, schrieb Mike Duigou:
I've tried to favour clarity and simplicity of language over brevity for
comments and mostly intended the comments for casual readers trying to
understanding the operation of the method rather than future maintainers.
OK, we are different. For me,
On 01/04/2011 02:02 AM, Ulf Zibis wrote:
Am 03.01.2011 21:16, schrieb Mike Duigou:
On Dec 24 2010, at 17:32 , Ulf Zibis wrote:
Am 23.12.2010 23:59, schrieb Paul Benedict:
Ulf, a previous email by Remi said only to invoke size() if the
collection is a Set.
Thanks I missed that.
My guess was,
Am 23.12.2010 23:59, schrieb Paul Benedict:
Ulf, a previous email by Remi said only to invoke size() if the collection is a
Set.
Thanks I missed that.
My guess was, that size() should be always faster than instantiating an iterator for the final
for-loop, and then seeing, that there is no
Mike,
I'm happy with the latest wording, it looks much better.
-Chris.
On 23/12/2010 01:23, Mike Duigou wrote:
Here's another try that tries to use similar wording to Collection:
*
*pCare must also be exercised when using collections that have
* restrictions on the elements
I have updated the webrev with the javadoc changes (identical to below) and
Ulf's suggested code changes:
http://cr.openjdk.java.net/~mduigou/6728865.3/webrev/
Mike
On Dec 23 2010, at 02:02 , Chris Hegarty wrote:
Mike,
I'm happy with the latest wording, it looks much better.
-Chris.
Am 23.12.2010 20:46, schrieb Mike Duigou:
I have updated the webrev with the javadoc changes (identical to below) and
Ulf's suggested code changes:
http://cr.openjdk.java.net/~mduigou/6728865.3/webrev/
Thanks, I could convince you mostly.
But, IMO, the inner comments are too expatiated (less
Am 23.12.2010 22:24, schrieb Ulf Zibis:
Aren't the explanation comments from my last example clear enough and more
fluently readable?
For clarification:
// collections to iterate and examine containment on
Collection? iterate = c1;
Collection? contains = c2;
Am 23.12.2010 22:24, schrieb Ulf Zibis:
Aren't the explanation comments from my last example clear enough and more
fluently readable?
Shouldn't we examine the size at first? :
// collections to iterate and examine containment on
Collection? iterate = c1;
Collection?
Ulf, a previous email by Remi said only to invoke size() if the collection
is a Set.
Paul
On Thu, Dec 23, 2010 at 4:24 PM, Ulf Zibis ulf.zi...@gmx.de wrote:
Am 23.12.2010 22:24, schrieb Ulf Zibis:
Aren't the explanation comments from my last example clear enough and more
fluently readable?
Mike,
On 12/21/10 09:38 PM, Mike Duigou wrote:
Thanks. That's an important clarification to include. Here's the revised text:
*
*pCare must also be exercised when using collections that do not permit
* calling the {...@code contains} method with a {...@code null} value. If
Hi Chris,
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Mike,
On 12/21/10 09:38 PM, Mike Duigou wrote:
Thanks. That's an important clarification to include. Here's the
revised text:
*
*pCare must also be exercised when using collections that do
not permit
* calling the
On 12/22/10 03:07 PM, Rémi Forax wrote:
Hi Chris,
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Mike,
On 12/21/10 09:38 PM, Mike Duigou wrote:
Thanks. That's an important clarification to include. Here's the
revised text:
*
*pCare must also be exercised when using collections that do not
On 12/22/2010 04:10 PM, Chris Hegarty wrote:
On 12/22/10 03:07 PM, Rémi Forax wrote:
Hi Chris,
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Mike,
On 12/21/10 09:38 PM, Mike Duigou wrote:
Thanks. That's an important clarification to include. Here's the
revised text:
*
*pCare must also be
On 12/22/10 03:34 PM, Gregg Wonderly wrote:
On 12/22/2010 9:10 AM, Chris Hegarty wrote:
On 12/22/10 03:07 PM, Rémi Forax wrote:
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Have we thought about catching/swallowing these exceptions?
What do you want to do in the catch block ?
Would it
On 12/22/10 03:30 PM, Rémi Forax wrote:
...
Would it make sense to simply swallow the exception ( do nothing ) and
continue with the next element? Clearly if contains() throws and
Exception then the collection does not contain the given element?
I see,
but the same argument can be applied to
On 12/22/2010 04:55 PM, Chris Hegarty wrote:
On 12/22/10 03:34 PM, Gregg Wonderly wrote:
On 12/22/2010 9:10 AM, Chris Hegarty wrote:
On 12/22/10 03:07 PM, Rémi Forax wrote:
On 12/22/2010 02:45 PM, Chris Hegarty wrote:
Have we thought about catching/swallowing these exceptions?
What do you
I don't think we should be looking at changing the current behaviour at
all. Certainly not for JDK7 (rfe for 8 perhaps?)
I think the most we can do with the spec is add cautionary
(non-normative) notes.
David
Rémi Forax said the following on 12/23/10 02:49:
On 12/22/2010 04:55 PM, Chris
Here's another try that tries to use similar wording to Collection:
*
* pCare must also be exercised when using collections that have
* restrictions on the elements that they may contain. Collection
* implementations are allowed to throw exceptions for any operation
*
On 12/21/10 02:24 AM, David Holmes wrote:
Functionality looks okay to me.
I think those spec/doc clarifications may need to go through CCC though.
I agree with David, a CCC request should be filed for the spec changes.
We should agree the spec changes on this mailing list before proposing
Am 21.12.2010 02:48, schrieb Mike Duigou:
I've updated the webrev with Ulf's feedback.
http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/
I think your explanation belongs to both variables, contains and iterate.
Furthermore the iterated collection is the one with the major importance and
Am 21.12.2010 14:44, schrieb Ulf Zibis:
// As performance of Set's contains() is less than O(N/2),
// iteration is given to the remaining collection.
// For collections who's contains() are of the same complexity then
// best performance is achieved by
On Dec 21 2010, at 02:43 , Chris Hegarty wrote:
On 12/21/10 02:24 AM, David Holmes wrote:
Functionality looks okay to me.
I think those spec/doc clarifications may need to go through CCC though.
I agree with David, a CCC request should be filed for the spec changes. We
should agree the
I think that is still not quite right. The spec for Collection says that
a Collection that does not support adding null values may or may not
support looking them up. So in both places where you say does not
permit null values I think you should probably say does not permit
looking up null
Thanks. That's an important clarification to include. Here's the revised text:
*
* pCare must also be exercised when using collections that do not permit
* calling the {...@code contains} method with a {...@code null} value. If
either
* collection does not permit {...@code
Hi Mike,
Mike Duigou said the following on 12/20/10 10:29:
I have updated the webrev for CR 6728865 with Rémi's feedback. The new webrev
is at:
http://cr.openjdk.java.net/~mduigou/6728865.1/webrev/
The size() comparisons are now done only when both c1 and c2 are not sets and I
have removed
I've updated the webrev with Ulf's feedback.
http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/
The old heuristics:
1. If c1 is a Set then iterate over c2.
2. Iterate over the smaller Collection.
I believe that the || in the original should have been a
I've rearranged it as branches in
Functionality looks okay to me.
I think those spec/doc clarifications may need to go through CCC though.
David
Mike Duigou said the following on 12/21/10 11:48:
I've updated the webrev with Ulf's feedback.
http://cr.openjdk.java.net/~mduigou/6728865.2/webrev/
The old heuristics:
1. If c1
Hi, I think you could code shorter:
Collection? iterate;
Collection? contains;
if (c2 instanceof Set) {
// C2 or both are sets.
iterate = c1;
contains = c2;
} else if (c1 instanceof Set) {
// c1 is a Set, c2 is a
31 matches
Mail list logo
