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

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

Converting Sets

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

Contents

  Converting Sets Roedy Green <see_website@mindprod.com.invalid> - 2012-02-01 23:34 -0800
    Re: Converting Sets Mayeul <mayeul.marguet@free.fr> - 2012-02-02 12:47 +0100
      Re: Converting Sets Roedy Green <see_website@mindprod.com.invalid> - 2012-02-02 05:32 -0800
        Re: Converting Sets Mayeul <mayeul.marguet@free.fr> - 2012-02-02 16:06 +0100
          Re: Converting Sets markspace <-@.> - 2012-02-02 09:21 -0800
            Re: Converting Sets Jim Janney <jjanney@shell.xmission.com> - 2012-02-02 13:13 -0700
              Re: Converting Sets markspace <-@.> - 2012-02-02 13:46 -0800
            Re: Converting Sets Roedy Green <see_website@mindprod.com.invalid> - 2012-02-02 16:29 -0800
              Re: Converting Sets Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-02 17:34 -0800
                Re: Converting Sets Arne Vajhøj <arne@vajhoej.dk> - 2012-02-04 20:49 -0500
                  Re: Converting Sets Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-06 12:55 -0800
                    Re: Converting Sets Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 20:47 -0500
                      Re: Converting Sets Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-06 17:51 -0800
                        Re: Converting Sets Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 20:57 -0500
              Re: Converting Sets markspace <-@.> - 2012-02-03 14:12 -0800
                Re: Converting Sets Lew <lewbloch@gmail.com> - 2012-02-03 22:32 -0800
              Re: Converting Sets Lew <lewbloch@gmail.com> - 2012-02-03 22:30 -0800
            Re: Converting Sets Lew <lewbloch@gmail.com> - 2012-02-03 22:33 -0800
        Re: Converting Sets Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-02 11:02 -0800
      Re: Converting Sets Roedy Green <see_website@mindprod.com.invalid> - 2012-02-02 18:25 -0800
        Re: Converting Sets markspace <-@.> - 2012-02-03 14:25 -0800

Page 1 of 2  [1] 2  Next page →

#11706 — Converting Sets

What is the cleanest way to do this conversion?

I have a Set<X>.
I want a Set<Y>  where X implements Y.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [next] | [standalone]

#11708

On 02/02/2012 08:34, Roedy Green wrote:
> What is the cleanest way to do this conversion?
>
> I have a Set<X>.
> I want a Set<Y>   where X implements Y.

This conversion exactly as asked:

Set<X> setOfX = obtainSetOfX();
Set<Y> setOfY = new YourPreferredSetImplementation<Y>(setOfX);

or:

Set<X> setOfX = obtainSetOfX();
Set<Y> setOfY = new YourPreferredSetImplementation<Y>();
setOfY.addAll(setOfX);

Conversion of a Set<X> to a Set<? extends Y>, ensuring the Set contains 
objects assignable to Y, but no new elements can be added to it:

Set<X> setOfX = obtainSetOfX();
Set<? extends Y> setOfY = setOfX;

Also, consider the possibility to build a Set<Y> and put X objects into 
it, in the first place.

--
Mayeul

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

#11709

On Thu, 02 Feb 2012 12:47:58 +0100, Mayeul <mayeul.marguet@free.fr>
wrote, quoted or indirectly quoted someone who said :

>Conversion of a Set<X> to a Set<? extends Y>, ensuring the Set contains 
>objects assignable to Y, but no new elements can be added to it:
>
>Set<X> setOfX = obtainSetOfX();
>Set<? extends Y> setOfY = setOfX;

This what I was looking for , that did not require an element by
element copy.
Ah, but this this you created is NOT a Set<Y>.  You cannot add
arbirary Y to it, just more X. I feel queasy. How could the compiler
keep track that setOfY could only contain X.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

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

#11711

On 02/02/2012 14:32, Roedy Green wrote:
> On Thu, 02 Feb 2012 12:47:58 +0100, Mayeul<mayeul.marguet@free.fr>
> wrote, quoted or indirectly quoted someone who said :
>
>> Conversion of a Set<X>  to a Set<? extends Y>, ensuring the Set contains
>> objects assignable to Y, but no new elements can be added to it:
>>
>> Set<X>  setOfX = obtainSetOfX();
>> Set<? extends Y>  setOfY = setOfX;
>
> This what I was looking for , that did not require an element by
> element copy.
> Ah, but this this you created is NOT a Set<Y>.  You cannot add
> arbirary Y to it, just more X. I feel queasy. How could the compiler
> keep track that setOfY could only contain X.

It cannot. The compiler notices that setOfY is parametered with an 
extends wildcard, and therefore does not know what exactly it can or 
cannot contain.

Therefore, you cannot add anything to setOfY. But you can still add more 
X to setOfX, and they point to the same object...

--
Mayeul

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

#11712

On 2/2/2012 7:06 AM, Mayeul wrote:
> On 02/02/2012 14:32, Roedy Green wrote:

>> Ah, but this this you created is NOT a Set<Y>. You cannot add
>> arbirary Y to it, just more X. I feel queasy. How could the compiler
>> keep track that setOfY could only contain X.

>
> It cannot.


I think this is covered in Effective Java.  Generics are a compile time 
thing.  If you want runtime, you have to roll your own (I don't know of 
any classes in the API that allow you to have a runtime type parameter, 
although I guess there may be some).

class MySet extends SomeSet {

   Class type;

   MySet( Class type ) { this.type = type; }

   void add( Object o ) {
     if( o instanceof type ) super.add( o );
   }
}

I think is the above is the gist of how EJ handles it.  Add a type token 
(the "type" variable) and test for types as they are added.  If you want 
generics too, add them in:

class MySet<T> extends Set<T> {

   Class<? extends T> type;

   MySet( Class<? extends T> type ) { this.type = type; }

   void add( T o ) {
     if( o instanceof type ) super.add( o );
   }
}

Not compiled, but I think that gives the right idea.

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

#11715

markspace <-@.> writes:

> On 2/2/2012 7:06 AM, Mayeul wrote:
>> On 02/02/2012 14:32, Roedy Green wrote:
>
>>> Ah, but this this you created is NOT a Set<Y>. You cannot add
>>> arbirary Y to it, just more X. I feel queasy. How could the compiler
>>> keep track that setOfY could only contain X.
>
>>
>> It cannot.
>
>
> I think this is covered in Effective Java.  Generics are a compile
> time thing.  If you want runtime, you have to roll your own (I don't
> know of any classes in the API that allow you to have a runtime type
> parameter, although I guess there may be some).
>
> class MySet extends SomeSet {
>
>   Class type;
>
>   MySet( Class type ) { this.type = type; }
>
>   void add( Object o ) {
>     if( o instanceof type ) super.add( o );
>   }
> }
>
> I think is the above is the gist of how EJ handles it.  Add a type
> token (the "type" variable) and test for types as they are added.  If
> you want generics too, add them in:
>
> class MySet<T> extends Set<T> {
>
>   Class<? extends T> type;
>
>   MySet( Class<? extends T> type ) { this.type = type; }
>
>   void add( T o ) {
>     if( o instanceof type ) super.add( o );
>   }
> }
>
> Not compiled, but I think that gives the right idea.

See checkedSet in java.util.Collections.

-- 
Jim Janney

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

#11716

On 2/2/2012 12:13 PM, Jim Janney wrote:
> See checkedSet in java.util.Collections.
>

Oh sure, find some documentation that completely contradicts me!

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

#11717

On Thu, 02 Feb 2012 09:21:13 -0800, markspace <-@.> wrote, quoted or
indirectly quoted someone who said :

>I think this is covered in Effective Java.  Generics are a compile time 
>thing

Everything else in Java eventually seems obvious.  Generics on the
other hand get weirder and weirder the more I learn.  I think it was a
mistake to try to do generics purely at compile time.  It is like
trying to do all types purely at compile time.

Have  we gone down that road too far now that Java can never be fixed
with run-time generics info without starting over with some completely
different notation? Then serialisation could work, containers could be
allocated with the precise array type.  You would not have so much
under-the-hood casting.

Perhaps it is time to read-read all the generics docs and see if they
make more sense now with some practical experience under my belt.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

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

#11719

On 2/2/12 4:29 PM, Roedy Green wrote:
> On Thu, 02 Feb 2012 09:21:13 -0800, markspace<-@.>  wrote, quoted or
> indirectly quoted someone who said :
>
>> I think this is covered in Effective Java.  Generics are a compile time
>> thing
>
> Everything else in Java eventually seems obvious.  Generics on the
> other hand get weirder and weirder the more I learn.  I think it was a
> mistake to try to do generics purely at compile time.  It is like
> trying to do all types purely at compile time.
That is exactly what Generics are.
>
> Have  we gone down that road too far now that Java can never be fixed
> with run-time generics info without starting over with some completely
> different notation? Then serialisation could work, containers could be
> allocated with the precise array type.  You would not have so much
> under-the-hood casting.
The point of generics is to add compile-time type safety. Runtime 
"generics" is a contradiction to that.  It might not have been 
implemented in the "cleanest possible" way, but it tends to be good 
enough for most non-reflective uses.

>
> Perhaps it is time to read-read all the generics docs and see if they
> make more sense now with some practical experience under my belt.
Yes, probably.

In particular, you want to understand what "<A extends B>" and
"<A super B>" mean when declaring generic types, and what "<? extends 
B>", "<? super B>" and "<?>" mean when /using/ generic types.

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

#11749

On 2/2/2012 8:34 PM, Daniel Pitts wrote:
> On 2/2/12 4:29 PM, Roedy Green wrote:
>> Have we gone down that road too far now that Java can never be fixed
>> with run-time generics info without starting over with some completely
>> different notation? Then serialisation could work, containers could be
>> allocated with the precise array type. You would not have so much
>> under-the-hood casting.
> The point of generics is to add compile-time type safety. Runtime
> "generics" is a contradiction to that.

That was the way it was decided to do it for Java.

But it did have to be that way.

And runtime check can certainly add to type safety!

Arne

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

#11759

On 2/4/12 5:49 PM, Arne Vajhøj wrote:
> On 2/2/2012 8:34 PM, Daniel Pitts wrote:
>> On 2/2/12 4:29 PM, Roedy Green wrote:
>>> Have we gone down that road too far now that Java can never be fixed
>>> with run-time generics info without starting over with some completely
>>> different notation? Then serialisation could work, containers could be
>>> allocated with the precise array type. You would not have so much
>>> under-the-hood casting.
>> The point of generics is to add compile-time type safety. Runtime
>> "generics" is a contradiction to that.
>
> That was the way it was decided to do it for Java.
>
> But it did have to be that way.
>
> And runtime check can certainly add to type safety!
Yes, I never said anything against that. I said generics were designed 
to add compile-time type safety. Runtime type safety is a different issue.

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

#11760

On 2/6/2012 3:55 PM, Daniel Pitts wrote:
> On 2/4/12 5:49 PM, Arne Vajhøj wrote:
>> On 2/2/2012 8:34 PM, Daniel Pitts wrote:
>>> On 2/2/12 4:29 PM, Roedy Green wrote:
>>>> Have we gone down that road too far now that Java can never be fixed
>>>> with run-time generics info without starting over with some completely
>>>> different notation? Then serialisation could work, containers could be
>>>> allocated with the precise array type. You would not have so much
>>>> under-the-hood casting.
>>> The point of generics is to add compile-time type safety. Runtime
>>> "generics" is a contradiction to that.
>>
>> That was the way it was decided to do it for Java.
>>
>> But it did have to be that way.
>>
>> And runtime check can certainly add to type safety!
> Yes, I never said anything against that. I said generics were designed
> to add compile-time type safety. Runtime type safety is a different issue.

Java generics was designed that way. There are nothing in the
generics concept that says it has to be that way.

Arne

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

#11761

On 2/6/12 5:47 PM, Arne Vajhøj wrote:
> On 2/6/2012 3:55 PM, Daniel Pitts wrote:
>> On 2/4/12 5:49 PM, Arne Vajhøj wrote:
>>> On 2/2/2012 8:34 PM, Daniel Pitts wrote:
>>>> On 2/2/12 4:29 PM, Roedy Green wrote:
>>>>> Have we gone down that road too far now that Java can never be fixed
>>>>> with run-time generics info without starting over with some completely
>>>>> different notation? Then serialisation could work, containers could be
>>>>> allocated with the precise array type. You would not have so much
>>>>> under-the-hood casting.
>>>> The point of generics is to add compile-time type safety. Runtime
>>>> "generics" is a contradiction to that.
>>>
>>> That was the way it was decided to do it for Java.
>>>
>>> But it did have to be that way.
>>>
>>> And runtime check can certainly add to type safety!
>> Yes, I never said anything against that. I said generics were designed
>> to add compile-time type safety. Runtime type safety is a different
>> issue.
>
> Java generics was designed that way. There are nothing in the
> generics concept that says it has to be that way.
Person A: Look at this green grass.
Person B: But Roses are red!

We're talking about Java generics, not about the concept of "generic" 
generics.

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

#11762

On 2/6/2012 8:51 PM, Daniel Pitts wrote:
> On 2/6/12 5:47 PM, Arne Vajhøj wrote:
>> On 2/6/2012 3:55 PM, Daniel Pitts wrote:
>>> On 2/4/12 5:49 PM, Arne Vajhøj wrote:
>>>> On 2/2/2012 8:34 PM, Daniel Pitts wrote:
>>>>> On 2/2/12 4:29 PM, Roedy Green wrote:
>>>>>> Have we gone down that road too far now that Java can never be fixed
>>>>>> with run-time generics info without starting over with some
>>>>>> completely
>>>>>> different notation? Then serialisation could work, containers
>>>>>> could be
>>>>>> allocated with the precise array type. You would not have so much
>>>>>> under-the-hood casting.
>>>>> The point of generics is to add compile-time type safety. Runtime
>>>>> "generics" is a contradiction to that.
>>>>
>>>> That was the way it was decided to do it for Java.
>>>>
>>>> But it did have to be that way.
>>>>
>>>> And runtime check can certainly add to type safety!
>>> Yes, I never said anything against that. I said generics were designed
>>> to add compile-time type safety. Runtime type safety is a different
>>> issue.
>>
>> Java generics was designed that way. There are nothing in the
>> generics concept that says it has to be that way.
> Person A: Look at this green grass.
> Person B: But Roses are red!
>
> We're talking about Java generics, not about the concept of "generic"
> generics.

The discussion was about whether runtime generics info could be added.

Limiting that discussion to current design choices does not make
much sense to me.

Arne

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

#11725

On 2/2/2012 4:29 PM, Roedy Green wrote:

> Perhaps it is time to read-read all the generics docs and see if they
> make more sense now with some practical experience under my belt.


If you feel seriously that you need more explanation, try O'Reilly's 
"Learning Java", third edition.  It has one of the better explanations 
of generics I've found.  It's big book to buy just for the generics 
section, but not really that much money in the grand scheme of things. 
Can you imagine some other way to pay $40 - $50 and get someone to 
explain a difficult programming concept?  I can't.

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

#11774

On Friday, February 3, 2012 2:12:46 PM UTC-8, markspace wrote:
> On 2/2/2012 4:29 PM, Roedy Green wrote:
> 
> > Perhaps it is time to read-read all the generics docs and see if they
> > make more sense now with some practical experience under my belt.

http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html

> If you feel seriously that you need more explanation, try O'Reilly's 
> "Learning Java", third edition.  It has one of the better explanations 
> of generics I've found.  It's big book to buy just for the generics 
> section, but not really that much money in the grand scheme of things. 
> Can you imagine some other way to pay $40 - $50 and get someone to 
> explain a difficult programming concept?  I can't.

-- 
Lew

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

#11772

On Thursday, February 2, 2012 4:29:09 PM UTC-8, Roedy Green wrote:
> On Thu, 02 Feb 2012 09:21:13 -0800, markspace <-@.> wrote, quoted or
> indirectly quoted someone who said :
> 
> >I think this is covered in Effective Java.  Generics are a compile time 
> >thing
> 
> Everything else in Java eventually seems obvious.  Generics on the
> other hand get weirder and weirder the more I learn.  I think it was a
> mistake to try to do generics purely at compile time.  It is like
> trying to do all types purely at compile time.

Nonsense. It's perfectly fine at compile time as far as it goes. You want to 
catch bugs at compile time rather than run time.

If you want generics at run time then add a type token.

Doing all types at compile time is the whole point of a strongly-typed language like Java. (OK, not all, but as much as you can.)

> Have  we gone down that road too far now that Java can never be fixed

If it were truly broken that'd be a good question.

> with run-time generics info without starting over with some completely
> different notation? Then serialisation could work, containers could be
> allocated with the precise array type.  You would not have so much
> under-the-hood casting.

This is an ancient and tired debate. Java does compile-time only with generics. 
Sadly, this forces the programmer to fully understand the type assertions they 
wish to make, and thus write better code. What a shame.

> Perhaps it is time to read-read all the generics docs and see if they
> make more sense now with some practical experience under my belt.

Generics is tricky. No question. Its difficulty exactly matches that of 
complete type analysis. Type analysis is tricky. No question. Its difficulty 
matches that of programming. Programming is tricky. No question.

-- 
Lew

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

#11773

markspace wrote:
> I think is the above is the gist of how EJ handles it.  Add a type token 
> (the "type" variable) and test for types as they are added.  If you want 
> generics too, add them in:

If you're using Java 5 or later, you not only want generics, you must use them 
where the type is generic. Per EJ.

-- 
Lew

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

#11713

On 2/2/12 5:32 AM, Roedy Green wrote:
> On Thu, 02 Feb 2012 12:47:58 +0100, Mayeul<mayeul.marguet@free.fr>
> wrote, quoted or indirectly quoted someone who said :
>
>> Conversion of a Set<X>  to a Set<? extends Y>, ensuring the Set contains
>> objects assignable to Y, but no new elements can be added to it:
>>
>> Set<X>  setOfX = obtainSetOfX();
>> Set<? extends Y>  setOfY = setOfX;
>
> This what I was looking for , that did not require an element by
> element copy.
> Ah, but this this you created is NOT a Set<Y>.  You cannot add
> arbirary Y to it, just more X. I feel queasy. How could the compiler
> keep track that setOfY could only contain X.
It does not. Instead, it prevents you from any add operation which 
requires the type.

In other words, setOfY becomes somewhat "read-only" for typed 
operations. You can still clear it, or sub-sets of it, but you can no 
longer add *any* object to it, whatever type.

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

#11720

On Thu, 02 Feb 2012 12:47:58 +0100, Mayeul <mayeul.marguet@free.fr>
wrote, quoted or indirectly quoted someone who said :

>> I want a Set<Y>   where X implements Y.
>
>This conversion exactly as asked:
>
>Set<X> setOfX = obtainSetOfX();
>Set<Y> setOfY = new YourPreferredSetImplementation<Y>(setOfX);

thanks. I have written an SSCCE to explain this in tedious detail.
See http://mindprod.com/jgloss/generics.html#CONVERTINGSETS
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web