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

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

What's the best way to make a cross string set?

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

Contents

  What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-27 12:12 -0700
    Re: What's the best way to make a cross string set? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-07-27 14:38 -0500
      Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-27 12:49 -0700
    Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-27 15:49 -0400
      Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-27 12:55 -0700
      Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-27 13:22 -0700
        Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-27 13:30 -0700
        Re: What's the best way to make a cross string set? Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-07-27 15:34 -0500
        Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-27 18:27 -0400
          Re: What's the best way to make a cross string set? lewbloch@gmail.com - 2017-07-28 18:51 -0700
      Re: What's the best way to make a cross string set? v_borchert@despammed.com (Volker Borchert) - 2017-07-29 06:03 +0000
    Re: What's the best way to make a cross string set? v_borchert@despammed.com (Volker Borchert) - 2017-07-28 18:19 +0000
      Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-28 13:28 -0700
        Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-28 17:20 -0400
          Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-31 05:24 -0700
            Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-31 12:01 -0400
              Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-31 10:58 -0700
            Re: What's the best way to make a cross string set? Sebastian <nowhere@nirvana.org> - 2017-07-31 18:13 +0200
            Re: What's the best way to make a cross string set? lewbloch@gmail.com - 2017-07-31 09:24 -0700
            Re: What's the best way to make a cross string set? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-31 19:24 -0400
          Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-01 06:36 -0700
            Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-01 10:58 -0400
              Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-01 08:09 -0700
                Re: What's the best way to make a cross string set? lewbloch@gmail.com - 2017-08-01 09:39 -0700
                  Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-01 10:18 -0700
                    Re: What's the best way to make a cross string set? Andreas Leitgeb <avl@logic.at> - 2017-08-02 09:22 +0000
                      Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-02 05:13 -0700
                        Re: What's the best way to make a cross string set? Andreas Leitgeb <avl@logic.at> - 2017-08-03 14:33 +0000
                          Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-03 08:51 -0700
                            Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-03 12:20 -0400
                              Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-03 10:15 -0700
                                Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-03 13:42 -0400
                                  Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-03 11:17 -0700
                                    Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-05 16:08 -0400
                                      Re: What's the best way to make a cross string set? Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-05 20:31 +0000
                                        Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-08-05 17:25 -0400
                                          Re: What's the best way to make a cross string set? Martin Gregorie <martin@address-in-sig.invalid> - 2017-08-05 22:11 +0000
                                            Re: What's the best way to make a cross string set? Sebastian <nowhere@nirvana.org> - 2017-08-06 18:13 +0200
                  Re: What's the best way to make a cross string set? Eric Douglas <e.d.programmer@gmail.com> - 2017-08-02 12:56 -0700
    Re: What's the best way to make a cross string set? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-29 16:55 -0400
    Re: What's the best way to make a cross string set? Sebastian <nowhere@nirvana.org> - 2017-07-29 23:56 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#37040

On Friday, July 28, 2017 at 5:21:09 PM UTC-4, Eric Sosman wrote:
>      If it's work work, you *really* should be using generics.
> Raw types are still supported in Java, yes -- for compatibility
> with existing code from more than thirteen years ago.  New code,
> even ten-year-old code, should not be using them except in dire
> dire dire circumstances.  So:
> 
> 	ArrayList list1 = new ArrayList()
> should have been something like
> 	List<List<String>> list1 = new ArrayList<>();
> or
> 	List<Collection<String>> list1 = new ArrayList<>();
> or even
> 	List<Iterable<String>> list1 = new ArrayList<>();
> and
> 	ArrayList list2 = new ArrayList()
> should have been
> 	List<String> list2 = new ArrayList<>();
> or maybe
> 	Collection<String> list2 = new ArrayList<>();
> ... and, of course, other variations are possible.
> 

So I enabled that warning, now I'm trying to parameterize everything.  Some of them are tough.  Now, how do I override?  It complains if I parameterize and it complains if I don't because they didn't.

http://docs.oracle.com/javase/8/docs/api/javax/swing/plaf/basic/BasicComboBoxRenderer.html#getListCellRendererComponent-javax.swing.JList-java.lang.Object-int-boolean-boolean-

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

#37041

On 8/1/2017 9:36 AM, Eric Douglas wrote:
> On Friday, July 28, 2017 at 5:21:09 PM UTC-4, Eric Sosman wrote:
>> [... use parameterized types ...]
> So I enabled that warning, now I'm trying to parameterize everything.  Some of them are tough.  Now, how do I override?  It complains if I parameterize and it complains if I don't because they didn't.
> 
> http://docs.oracle.com/javase/8/docs/api/javax/swing/plaf/basic/BasicComboBoxRenderer.html#getListCellRendererComponent-javax.swing.JList-java.lang.Object-int-boolean-boolean-

     Why in the world are you extending plaf classes?

     Calvin: "Do we have any chainsaws in the house?"
     His Mom: "No. Why?"
     Calvin: "Rats! How am I supposed to learn to juggle?"

-- 
esosman@comcast-dot-net.invalid
Twelve hundred sixty-eight days to go.

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

#37042

On Tuesday, August 1, 2017 at 10:58:39 AM UTC-4, Eric Sosman wrote:
> 
>      Why in the world are you extending plaf classes?
> 
>      Calvin: "Do we have any chainsaws in the house?"
>      His Mom: "No. Why?"
>      Calvin: "Rats! How am I supposed to learn to juggle?"
> 

Because that's the class it was using by default to render my JComboBox?
I'm overriding the getListCellRendererComponent to set the background color on the dropdown list.

That's beside the point.  The only thing I can see to do about that is stick with the raw type and add a @SuppressWarnings which shows as a problem if anyone editing the class is ignoring the warnings for rawtypes.

Another one I found we're extending, jfreechart has some active development but their latest public release from 2014 is still using raw types.  Eclipse doesn't like the Comparable class, and of course you can't not override an interface.

http://www.jfree.org/jfreechart/api/javadoc/org/jfree/chart/labels/PieSectionLabelGenerator.html

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

#37043

On Tuesday, August 1, 2017 at 8:10:16 AM UTC-7, Eric Douglas wrote:
> On Tuesday, August 1, 2017 at 10:58:39 AM UTC-4, Eric Sosman wrote:
> > 
> >      Why in the world are you extending plaf classes?
> > 
> >      Calvin: "Do we have any chainsaws in the house?"
> >      His Mom: "No. Why?"
> >      Calvin: "Rats! How am I supposed to learn to juggle?"
> > 
> 
> Because that's the class it was using by default to render my JComboBox?
> I'm overriding the getListCellRendererComponent to set the background color on the dropdown list.
> 
> That's beside the point.  The only thing I can see to do about that is stick with the raw type and add a @SuppressWarnings which shows as a problem if anyone editing the class is ignoring the warnings for rawtypes.

Do not use raw types. You haven't shown what your specific issue is, so no one will be able to answer "Some of them are tough.  Now, how do I override?" Maybe if you show some code and what is "tough" about it we can help.

Do not use raw types.

Really.

-- 
Lew

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

#37044

On Tuesday, August 1, 2017 at 12:40:16 PM UTC-4, lewb...@gmail.com wrote:
> On Tuesday, August 1, 2017 at 8:10:16 AM UTC-7, Eric Douglas wrote:
> > On Tuesday, August 1, 2017 at 10:58:39 AM UTC-4, Eric Sosman wrote:
> > > 
> > >      Why in the world are you extending plaf classes?
> > > 
> > >      Calvin: "Do we have any chainsaws in the house?"
> > >      His Mom: "No. Why?"
> > >      Calvin: "Rats! How am I supposed to learn to juggle?"
> > > 
> > 
> > Because that's the class it was using by default to render my JComboBox?
> > I'm overriding the getListCellRendererComponent to set the background color on the dropdown list.
> > 
> > That's beside the point.  The only thing I can see to do about that is stick with the raw type and add a @SuppressWarnings which shows as a problem if anyone editing the class is ignoring the warnings for rawtypes.
> 
> Do not use raw types. You haven't shown what your specific issue is, so no one will be able to answer "Some of them are tough.  Now, how do I override?" Maybe if you show some code and what is "tough" about it we can help.
> 
> Do not use raw types.
> 
> Really.
> 
> -- 
> Lew

As mentioned, the 2 cases I cannot overrun are overrides, one for the plaf, one for jfreechart.  I haven't checked if they've removed the raw from the latest jfreechart source but it is in the latest public build.

It took a few hours to remove all other raw references, even using Eclipse's auto-fix which is sometimes clueless.  It would add the parameter to the new statements, then add a second suggestion to remove the parameter and just leave the <>.  It would add <Object,Object> by default to every SwingWorker initialize, so I had to copy in the declared types.  Some places it tried to add <?> and I had to change to <Object>.  I've been writing this API for probably about 10 years, but it is nearly all me, and a lot of my coding is in another language.  I would guess bigger companies would have a lot more to update.  At least running some of my test classes everything appears to be working, so I have to assume Eclipse isn't letting me break code by parameterizing.

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

#37045

Eric Douglas <e.d.programmer@gmail.com> wrote:
> Some places it tried to add <?> and I had to change to <Object>.

Are you sure that you had to change it?  The <?> could be just fine
in many cases. It just means that the generics class itself doesn't
give a dime about it's parameter type or any restrictions on it.

It's certainly *not* just eclipse saying "dunno".

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

#37046

On Wednesday, August 2, 2017 at 5:27:01 AM UTC-4, Andreas Leitgeb wrote:
> Are you sure that you had to change it?  The <?> could be just fine
> in many cases. It just means that the generics class itself doesn't
> give a dime about it's parameter type or any restrictions on it.
> 
> It's certainly *not* just eclipse saying "dunno".

Yes, for instance I have a method declared as

     protected Comparable<Object> getCompareValue() {

I call this method from

     final Comparable compareMe = getCompareValue();

Eclipse auto-changes this to

     final Comparable<Comparable<?>> compareMe = getCompareValue();

and flags it as an error "cannot convert Comparable<Object> to Comparable<Comparable<?>>"

If I just fix it to match it works fine.

     final Comparable<Object> compareMe = getCompareValue();

Somehow Eclipse didn't know it needed to be Comparable<Object> even though it auto-added the <Object> to the return value on the method.

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

#37054

Eric Douglas <e.d.programmer@gmail.com> wrote:
> On Wednesday, August 2, 2017 at 5:27:01 AM UTC-4, Andreas Leitgeb wrote:
>> Are you sure that you had to change it?  The <?> could be just fine
>> in many cases. It just means that the generics class itself doesn't
>> give a dime about it's parameter type or any restrictions on it.
>> It's certainly *not* just eclipse saying "dunno".
> Yes, for instance I have a method declared as
>      protected Comparable<Object> getCompareValue() {
> I call this method from
>      final Comparable compareMe = getCompareValue();
> Eclipse auto-changes this to
>      final Comparable<Comparable<?>> compareMe = getCompareValue();

I cannot reproduce that with my (oldish) Eclipse 3.8.1 here.
With "add type arguments" it seems to just add "<?>", and
with "Change type to Comparable<Object>" it obviously changes
it to Comparable<Object>, but I didn't get it to change it to
Comparable<Comparable<?>>.

Generally, Comparable<Object> makes little sense based on what 
Comparable is designed for, namely as an anti-symmetric operation.
I was even surprised that Comparable does not restrict its type
argument, but then I remembered that were it defined like
  Comparable<T extends Comparable<T>>
then it wouldn't be possible to use it with anonymous classes.

Maybe a newer eclipse than mine has some hardcoded "knowledge"
of Comparable and therefore tries to make something more sensible
than the locked-down interface would imply.

> If I just fix it to match it works fine.
>      final Comparable<Object> compareMe = getCompareValue();

Consider changing already getCompareValue() to return something
better than Comparable<Object>.

> Somehow Eclipse didn't know it needed to be Comparable<Object>
> even though it auto-added the <Object> to the return value on
> the method.

That might have been deduced from your implementation of getCompareValue().

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

#37055

On Thursday, August 3, 2017 at 10:37:49 AM UTC-4, Andreas Leitgeb wrote:
> Generally, Comparable<Object> makes little sense based on what 
> Comparable is designed for, namely as an anti-symmetric operation.
> I was even surprised that Comparable does not restrict its type
> argument, but then I remembered that were it defined like
>   Comparable<T extends Comparable<T>>
> then it wouldn't be possible to use it with anonymous classes.
> 

This was for a custom Comparable class which can have multiple states.  In one it returns a String, in another it returns an Integer from getCompareValue().  The comparator sorts these, grouping the values together by the compare type.

> Maybe a newer eclipse than mine has some hardcoded "knowledge"
> of Comparable and therefore tries to make something more sensible
> than the locked-down interface would imply.
> 

I'm running 4.7.0.

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

#37056

On 8/3/2017 11:51 AM, Eric Douglas wrote:
> On Thursday, August 3, 2017 at 10:37:49 AM UTC-4, Andreas Leitgeb wrote:
>> Generally, Comparable<Object> makes little sense based on what
>> Comparable is designed for, namely as an anti-symmetric operation.
>> I was even surprised that Comparable does not restrict its type
>> argument, but then I remembered that were it defined like
>>    Comparable<T extends Comparable<T>>
>> then it wouldn't be possible to use it with anonymous classes.
>>
> 
> This was for a custom Comparable class which can have multiple states.  In one it returns a String, in another it returns an Integer from getCompareValue().  The comparator sorts these, grouping the values together by the compare type.

     If you're using a Comparator, how does Comparable enter
into the discussion?

-- 
esosman@comcast-dot-net.invalid
Twelve hundred sixty-six days to go.

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

#37057

On Thursday, August 3, 2017 at 12:20:29 PM UTC-4, Eric Sosman wrote:
> 
>      If you're using a Comparator, how does Comparable enter
> into the discussion?
> 

Isn't there always a comparator for a comparable?
I mean I just call the sort method on an array of instances of this custom class.  It is Comparable, it compares to other instances of itself.

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

#37058

On 8/3/2017 1:15 PM, Eric Douglas wrote:
> On Thursday, August 3, 2017 at 12:20:29 PM UTC-4, Eric Sosman wrote:
>>
>>       If you're using a Comparator, how does Comparable enter
>> into the discussion?
>>
> 
> Isn't there always a comparator for a comparable?

     No.  This isn't the first thread in which you've mixed up
Comparable and Comparator.  Perhaps a refresher course in Java
basics would be in order.

> I mean I just call the sort method on an array of instances of this custom class.  It is Comparable, it compares to other instances of itself.

     ... so you're not using a Comparator.  Okay ... but you probably
should be.  An object whose internal state switches between "Now I'm
using one of my Strings to decide my order, oh, wait, no, I'm using
an Integer instead" is a design that's just asking for trouble:

	Thing thing1 = ...;
	thing1.setSortOrder(Thing.USE_STRING);
	Thing thing2 = ...;
	thing2.setSortOrder(Thing.USE_INTEGER);

See the problem yet?  Okay, keep going:

	int compare12 = thing1.compare(thing2);  // uses String (?)
	int compare21 = thing2.compare(thing1);  // uses Integer (?)

Now you might discover that thing1 > thing2 AND thing2 > thing1 ...

     If you sometimes want to sort by the String and sometimes by the
Integer, ditch Comparable (or use it for just one of the orderings)
and use Comparators:

	Comparator<Thing> byString =
	    (p,q) -> p.getString().compareTo(q.getString());

	Comparator<Thing> byInteger =
	    (p, q) -> p.getInteger().compareTo(q.getInteger());

	Thing[] array = ...;
	Arrays.sort(array, byString);
	...
	Arrays.sort(array, byInteger);
	...

or even

	Thing[] array = ...;
	boolean how = ...;
	Arrays.sort(array, how ? byString : byInteger);
	...

or even

	Arrays.sort(array,
	    (p, q) -> p.getStoned().compareTo(q.getStoned()));
	...

-- 
esosman@comcast-dot-net.invalid
Twelve hundred sixty-six days to go.

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

#37059

On Thursday, August 3, 2017 at 1:42:53 PM UTC-4, Eric Sosman wrote:
>      No.  This isn't the first thread in which you've mixed up
> Comparable and Comparator.  Perhaps a refresher course in Java
> basics would be in order.
> 

That is beside the point, but when I call Arrays.sort() I'm thinking of their method as the comparator.  It calls my compareTo method and puts the set of custom objects in order, isn't that what a comparator does?

> > I mean I just call the sort method on an array of instances of this custom class.  It is Comparable, it compares to other instances of itself.
> 
>      ... so you're not using a Comparator.  Okay ... but you probably
> should be.  An object whose internal state switches between "Now I'm
> using one of my Strings to decide my order, oh, wait, no, I'm using
> an Integer instead" is a design that's just asking for trouble:
> 
> 	Thing thing1 = ...;
> 	thing1.setSortOrder(Thing.USE_STRING);
> 	Thing thing2 = ...;
> 	thing2.setSortOrder(Thing.USE_INTEGER);
> 
> See the problem yet?  Okay, keep going:
> 
> 	int compare12 = thing1.compare(thing2);  // uses String (?)
> 	int compare21 = thing2.compare(thing1);  // uses Integer (?)
> 
> Now you might discover that thing1 > thing2 AND thing2 > thing1 ...
> 

It is groupings, not just comparing Object to Object which would have issues with comparing a String to an Integer.
It's like this.
public class MyComparableClass implements Comparable<MyCustomClass> {
private short style;
public final short sSTYLE = 0;
public final short iSTYLE = 1;
private String sValue;
private int iValue;
public void setStyle(final short newstyle){
style=newstyle;
}
public Short getStyle(){
return style;
}
public void setString(final String value){
sValue=value;
}
public String getString(){
return sValue;
}
public void setInt(final int value){
iValue=value;
}
public Integer getInt(){
return iValue;
}
protected Comparable<Object getCompareValue(){
Object compareValue;
switch(style){
case sSTYLE:
compareValue=sValue;
break;
case iSTYLE:
compareValue=iValue;
break;
}
return (Comparable<Object>)compareValue;
}
public int compareTo(final MyComparableClass o){
final Comparable<Object> compareMe = getCompareValue();
final Comparable<Object> compareMeTo = o.getCompareValue();
if (getStyle().equals(o.getStyle())){
return compareMe.compareTo(compareMeTo);
}
return getStyle().compareTo(o.getStyle());
}
}

>      If you sometimes want to sort by the String and sometimes by the
> Integer, ditch Comparable (or use it for just one of the orderings)
> and use Comparators:
> 
> 	Comparator<Thing> byString =
> 	    (p,q) -> p.getString().compareTo(q.getString());
> 
> 	Comparator<Thing> byInteger =
> 	    (p, q) -> p.getInteger().compareTo(q.getInteger());
> 
> 	Thing[] array = ...;
> 	Arrays.sort(array, byString);
> 	...
> 	Arrays.sort(array, byInteger);
> 	...
> 
> or even
> 
> 	Thing[] array = ...;
> 	boolean how = ...;
> 	Arrays.sort(array, how ? byString : byInteger);
> 	...
> 
> or even
> 
> 	Arrays.sort(array,
> 	    (p, q) -> p.getStoned().compareTo(q.getStoned()));
> 	...
> 

This would require all objects in a collection to be the same style?

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

#37067

[Re-sending; earlier follow-up vanished into the ether.]

On 8/3/2017 2:17 PM, Eric Douglas wrote:
 > [...]
 > It is groupings, not just comparing Object to Object which would have 
issues with comparing a String to an Integer.

     Not sure what you mean by "it is groupings."  In any event,
both Comparable::compareTo and Comparator::compare perform a
pairwise comparison.

 > It's like this.
 > public class MyComparableClass implements Comparable<MyCustomClass> {
 > private short style;
 > public final short sSTYLE = 0;
 > public final short iSTYLE = 1;

     Aside: Why are these not static?

 > private String sValue;
 > private int iValue;
 > public void setStyle(final short newstyle){
 > style=newstyle;
 > }
 > public Short getStyle(){
 > return style;
 > }
 > public void setString(final String value){
 > sValue=value;
 > }
 > public String getString(){
 > return sValue;
 > }
 > public void setInt(final int value){
 > iValue=value;
 > }
 > public Integer getInt(){
 > return iValue;
 > }
 > protected Comparable<Object getCompareValue(){

     Aside: Missing a >, I think.

 > Object compareValue;
 > switch(style){
 > case sSTYLE:
 > compareValue=sValue;
 > break;
 > case iSTYLE:
 > compareValue=iValue;
 > break;
 > }
 > return (Comparable<Object>)compareValue;

     Aside: Compile error here.

 > }
 > public int compareTo(final MyComparableClass o){
 > final Comparable<Object> compareMe = getCompareValue();
 > final Comparable<Object> compareMeTo = o.getCompareValue();
 > if (getStyle().equals(o.getStyle())){
 > return compareMe.compareTo(compareMeTo);
 > }
 > return getStyle().compareTo(o.getStyle());

     Crux: This is going "all the way around Robin Hood's barn"
to accomplish something that could be done in a far simpler way,
such as

     class Thing implements Comparable<Thing> {
         // ... statics (and noise)

         private short style;
         private String sValue;
         private int iValue;

         // ... constructors, getters, setters (and spaniels)

         @Override
         public int compareTo(Thing that) {
             int result = this.style - that.style;
             if (result == 0) {
                 switch (style) {
                 case sStyle:
                     result = this.sValue.compareTo(that.sValue);
                     break;
                 case iStyle:
                     result = Integer.compare(
                         this.iValue, that.iValue);
                     break;
                 default:
                     throw new IllegalStateException(
                         "poor style: " + style;
                 }
             }
             return result;
         }
     }

... and that's all: A simple multi-key comparison.  None of this
nonsense about pretending to be Comparable<EverythingImaginable>,
which of course isn't possible to do in a sensible way.

[The above is from two days ago; here's an addendum:]

     Upon reflection, strike "in a sensible way" and replace with
"at all, without violating the contract of Comparable."  The
problem is that Comparable must implement a /total order/, which
means (among other things) that it must be asymmetric: The sign
of x.compareTo(y) must be opposite that of y.compareTo(x), or
both must be zero.  Now, you may contrive a class that claims to
implement Comparable<Object> and endow it with a compareTo()
method that does, in fact, accept any kind of Object and return
some kind of result:

	class MyStrangeClass implements Comparable<Object> {
	   public int compareTo(Object obj) { ... }
	   ...
	}

	MyStrangeClass x = ...
	JButton y = new JButton("DO NOT PRESS");
	int xy = x.compareTo(y);

Fine so far, but then

	int yx = y.compareTo(x);

... won't even compile, much less return a result whose sign is
opposite that of xy.  You can't implement Comparable<Object>
properly unless you make *every* class implement it, and make
them all implement it consistently (that is, if a particular
Random compares greater than a specific OutputStream, the
OutputStream must also compare less than the Random).  Good
luck with that ...

     (Andreas Leitgeb wrote about this briefly two days ago;
it's only now begun to penetrate my thick skull.)

-- 
esosman@comcast-dot-net.invalid
Twelve hundred sixty-four days to go.

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

#37068

On Sat, 05 Aug 2017 16:08:36 -0400, Eric Sosman wrote:

>      Upon reflection, strike "in a sensible way" and replace with
> "at all, without violating the contract of Comparable."  The problem is
> that Comparable must implement a /total order/, which means (among other
> things) that it must be asymmetric: The sign of x.compareTo(y) must be
> opposite that of y.compareTo(x), or both must be zero.  Now, you may
> contrive a class that claims to implement Comparable<Object> and endow
> it with a compareTo() method that does, in fact, accept any kind of
> Object and return some kind of result
>
There are other implications that seem to me to make this an absolute 
requirement. Eric's switchable comparison would have severe side effects 
on other classes, e.g. changing his style switch setting should logically 
force a SortedMap to automatically reorder itself. 


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

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

#37069

On 8/5/2017 4:31 PM, Martin Gregorie wrote:
> On Sat, 05 Aug 2017 16:08:36 -0400, Eric Sosman wrote:
> 
>>       Upon reflection, strike "in a sensible way" and replace with
>> "at all, without violating the contract of Comparable."  The problem is
>> that Comparable must implement a /total order/, which means (among other
>> things) that it must be asymmetric: The sign of x.compareTo(y) must be
>> opposite that of y.compareTo(x), or both must be zero.  Now, you may
>> contrive a class that claims to implement Comparable<Object> and endow
>> it with a compareTo() method that does, in fact, accept any kind of
>> Object and return some kind of result
>>
> There are other implications that seem to me to make this an absolute
> requirement. Eric's switchable comparison would have severe side effects
> on other classes, e.g. changing his style switch setting should logically
> force a SortedMap to automatically reorder itself.

     It turns out that he's not trying to change the ordering
rule in mid-stream (at least, he didn't show any such attempt).
Rather, he's got an obfuscated way of implementing a two-part
key: The first part is this "style" number, and if the numbers
agree the second is either a String or an int (disguised as an
Integer), depending on the style.

     True, if he were to change the style of an object already
in a SortedSomething then the fertilizer would hit the fan.
But that's just a particular case of the general caution against
mutating an object that's in a Set or Map or other value-sensitive
data structure.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred sixty-four days to go.

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

#37070

On Sat, 05 Aug 2017 17:25:44 -0400, Eric Sosman wrote:

>      It turns out that he's not trying to change the ordering
> rule in mid-stream (at least, he didn't show any such attempt). Rather,
> he's got an obfuscated way of implementing a two-part key: The first
> part is this "style" number, and if the numbers agree the second is
> either a String or an int (disguised as an Integer), depending on the
> style.
>
OK, but thats a pretty poor way of implementing a two-part key, or an n-
part key for that matter. Assuming that a is a more significant part than 
b, then the comparison should rather be something like this:

int compareTo(Thing thing)
{
   int r1 = a.compare-to(thing.geta());
   if (r1 != 0) 
      return r1
   else
      return b.compareTo(thing.getb());
}

with the restriction that all multipart key elements must be accessable 
to getters or must not be protected or private: an not unreasonable 
restriction.

>      True, if he were to change the style of an object already
> in a SortedSomething then the fertilizer would hit the fan.
> But that's just a particular case of the general caution against
> mutating an object that's in a Set or Map or other value-sensitive data
> structure.
>
I suspect this may be at least part of why other ordered structures such 
as TreeMap and HashMap use a separate key. Often this is going to be 
handled via a getter, e.g. tree.put(thing.getKey(), thing); but it 
doesn't have to be used this way.


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

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

#37072

Am 06.08.2017 um 00:11 schrieb Martin Gregorie:
> On Sat, 05 Aug 2017 17:25:44 -0400, Eric Sosman wrote:
>
>>      It turns out that he's not trying to change the ordering
>> rule in mid-stream (at least, he didn't show any such attempt). Rather,
>> he's got an obfuscated way of implementing a two-part key: The first
>> part is this "style" number, and if the numbers agree the second is
>> either a String or an int (disguised as an Integer), depending on the
>> style.
>>
> OK, but thats a pretty poor way of implementing a two-part key, or an n-
> part key for that matter. Assuming that a is a more significant part than
> b, then the comparison should rather be something like this:
>
> int compareTo(Thing thing)
> {
>    int r1 = a.compare-to(thing.geta());
>    if (r1 != 0)
>       return r1
>    else
>       return b.compareTo(thing.getb());
> }
>
> with the restriction that all multipart key elements must be accessable
> to getters or must not be protected or private: an not unreasonable
> restriction.
>
[mutability concerns snipped]

I think it would probably be better to pass explicit Comparators to the 
TreeMap etc. here, instead of making Thing implement Comparator. With 
Java's functional constructs (I wonder why they are so seldomly 
mentioned in this newsgroup) you can easily separate key-definition and 
comparison proper, which allows you to combine multiple "elementary" 
comparators without having to reinvent the wheel (the cascading 
comparison logic) each time. Like:

static Comparator<Thing> byStyle = Comparator.comparing(Thing::getStyle);

static Comparator<Thing> bySomeValue = 
Comparator.comparing(Thing::getStyleDependentSortKey);

... perhaps more

static Comparator<Thing> multiKey = byStyle.thenComparing(bySomeValue);

-- Sebastian

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

#37047

On Tuesday, August 1, 2017 at 12:40:16 PM UTC-4, lewb...@gmail.com wrote:
override?" Maybe if you show some code and what is "tough" about it we can help.
> 

So here's a tough one.  Try this, start with an abstract class:

public abstract class TestAbstractClass {

}

Then parameterize this raw class.  This compiles as is.

public class TestParameterizeClass<MyCustomType extends TestAbstractClass> {

     final public static MyContainer test = new MyContainer();
     protected static class MyContainer {
          public void testMethod(final Class testVar) {
               
          }
     }
     private Class testClass;
     public void compileMe() {
          test.testMethod(testClass);
     }
}

I attempted:

public class TestParameterizeClass<MyCustomType extends TestAbstractClass> {

     final public static MyContainer<? extends TestAbstractClass> test = new MyContainer<>();
     protected static class MyContainer<MyCustomType extends TestAbstractClass> {
          public void testMethod(final Class<MyCustomType> testVar) {
               
          }
     }
     private Class<MyCustomType> testClass;
     public void compileMe() {
          test.testMethod(testClass);
     }
}

I get down to test.testMethod(testClass) and Eclipse tells me:

The method testMethod(Class<capture#1-of ? extends TestAbstractClass>) in the type TestParameterizeClass.MyContainer<capture#1-of ? extends TestAbstractClass> is not applicable for the arguments (Class<MyCustomType>)

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

#37028

On 7/29/2017 12:47 PM, Stefan Ram wrote:
> Eric Douglas <e.d.programmer@gmail.com> writes:
>> Now I want to print only the complete set, as in
> 
>    My solution uses lines some of which contain more
>    than 80 characters.

     There's an extremely simple fix for that ... :)

>    It tries to avoid recursion so as to be efficient
>    and not require too much stack space.

     Consider how much stack space is saved: An amount proportional
to the number of List<String>'s in the containing List<List<String>>.
I suggest that if the outer List's size is great enough to threaten
stack overflow, then the running time of the program is likely to
exceed the lifetime of the computer (unless nearly all of the inner
Lists are of size 1.)

     For example, suppose that stack space begins to be a concern
at a depth of just one hundred recursive calls (it probably isn't,
but perhaps the recursion starts when we're already several thousand
stack frames deep).  If the outer List holds one hundred inner
Lists, each containing just two Strings, the program will generate
2**100 ~= 1E30 lines of output.  With an extraordinarily fast
computer and a ludicrously fast output device we might hope to
generate a line every nanosecond, so the running time would be
at least 1E21 seconds -- about forty trillion years.

     In other words: If the problem is runnable in reasonable
time, it follows that stack space is not a concern, not at all.

-- 
esosman@comcast-dot-net.invalid
Twelve hundred seventy-one days to go.

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web