• MGS (unregistered) in reply to RangerNS
    Anonymous:
    Anonymous:
    Anonymous:

    Back on topic, I've seen latex gloves coming in "pairs of three" so you had an extra one in case one broke in the middle of your dish washing. Maybe this was a glove factory stock system?

    So the third glove had the thumb in the middle? 

     

    Nope, it would have been just a "thumb"

     

     

    In other words: a condom. 

  • (cs)

    Or perhaps the programmer is an Eric Satie fan, having just played Three Pieces in the Form of a Pair.

  • triglyceride (unregistered)

    now i get it, the Pair implementation is not type safe!

    This is the way to do it:

    public class Pair <K, V, E>
{
    private K first;
    private V second;
    private E third;
    public Pair() { }
    public Pair( K first, V second, E third )
    {
        this.first  = first;
        this.second  = second;
        this.third  = third;
    }
    public K getFirst()  { return first; }
    public V getSecond() { return second; }
    public E getThird()  { return third; }
    public void setFirst( K first  )  { this.first  = first; }
    public void setSecond( V second ) { this.second  = second; }
    public void setThird( E third  )  { this.third  = third; }
}
  • CaptchaFillerOutEr (unregistered) in reply to jkohen

    In which case it would be:

     Mi compadre e yo
     

  • CH (unregistered) in reply to Phalphalak
    Phalphalak:
    public final E getSecond() {
            return e;
        }

        public final void setFirst(E e) {
            this.e = e;
        }

        public final T getFirst() {
            return t;
        }

        public final void setSecond(T t) {
            this.t = t;
        }

    So wait a minute... setFirst sets the variable retrieved by getSecond and getFirst retrieves the variable set by setSecond?

    knowhutimean [captcha]

  • (cs) in reply to MGS
    Anonymous:
    Phalphalak:

    I keep my own java library with useful methods and classes and pair has to proofen to be one of the most usefuls ones. For some geometric algorithms I required to temporarily associate Points with an index. I think it would be inappropriate to especially define a IndexedPoint class for that. Instead I simply used a Pair<Integer,Point>. I think that is a good example of when utilizing such classes makes sense.

    Uh... Any reason why you wouldn't use a HashMap for that? 

     Why should I use a hashmap for two elements? That would result in quite an overhead.
     

  • jkohen (unregistered) in reply to CaptchaFillerOutEr
    Anonymous:

    In which case it would be:

     Mi compadre e yo
     

     

    No, not really... look up «"y yo" spanish» in Google.com. You'll find loads of book titles and Spanish courses using this construction, but no references to "e yo." There are even some literature classics such as "Platero y yo." I guess it comes down to the sound of "y" not being exactly the same as "i," and maybe the former not being a vowel in Spanish. For instance, we pronounce the "y" and "ll" as "sh" around here, in Buenos Aires.

  • rgz (unregistered) in reply to CaptchaFillerOutEr

    nope, it's "mi compadre y yo". You see, "y" is only replaced by "e" when the following word starts with an /i/ sound. In the case of "yo" the "y" is pronounced like the "g" "George", or more like the "dj" in "Django".

     so it is "mi compadre y djo" = "mi compadre y yo"

     Of course "dj" is not a valid spanish construction, it is only intented as an example.

    BTW i'm a native speaker.

    Captcha: java... can't say anything funny about java, java ain't no fun. 

  • (cs) in reply to CH

    Lol! Thanks for pointing that out. It seems I never used the set-method which kept me from noticing. :)

  • Jesus Herman Christ (unregistered)

    someone post the picture of http://www.health.sa.gov.au/Default.aspx?tabid=48


    the error message has now turned to 'General network error. Check your network documentation.'

  • John Rudd (unregistered)

    I'm sure it's just the OO Purist in me, but I've spotted things in this one, that don't belong, that no one else has mentioned.Specifically:public Object getFirst() { return first; }public Object getSecond() { return second; }  public Object getThird() { return third; }  public void setFirst( Object first ) { this.first = first; }  public void setSecond( Object second ) { this.second = second; }  public void setThird( Object third ) { this.third = third; }Defining accessor methods in what ought to be an abstract class!?  BAH!!!Philistines.(Captcha: stfu)

  • MGS (unregistered) in reply to Phalphalak
    Phalphalak:
    Anonymous:
    Phalphalak:

    I keep my own java library with useful methods and classes and pair has to proofen to be one of the most usefuls ones. For some geometric algorithms I required to temporarily associate Points with an index. I think it would be inappropriate to especially define a IndexedPoint class for that. Instead I simply used a Pair<Integer,Point>. I think that is a good example of when utilizing such classes makes sense.

    Uh... Any reason why you wouldn't use a HashMap for that? 

     Why should I use a hashmap for two elements? That would result in quite an overhead.
     

     I took your description to indicate that you were working with a set of some kind.  But I guess you were talking about using the 'pair' as an attribute of some object.  Certainly that usage makes sense.
     

  • mcguire (unregistered) in reply to John Bigboote
    John Bigboote:
    Anonymous:
    jackass:

    You really have to wonder what their class that only deals with two variables is called.

     

    I bet it's "Singleton". 

     

    In keeping with the genital theme, my money's on "Unit." 

     

    You lack imagination.  It's gotta be "Quintuplet".  Or perhaps "Fred". 

  • Exick (unregistered)

    This reminds me of my high school baseball coach who used to tell us to "pair up into groups of 3" and to "circle up in a square".


    Captcha: mustache 

  • JL (unregistered) in reply to seer
    Anonymous:

    A ternary pair tree? A tree-o-nulls? I love it! Actually, a proper pair-implementation could still provide the extra args

    Of course, such a pair-tree would be ideal for storing Partridge objects.

  • andy (unregistered) in reply to seer
    Anonymous:
    Anonymous:
    Anonymous:

    Back on topic, I've seen latex gloves coming in "pairs of three" so you had an extra one in case one broke in the middle of your dish washing. Maybe this was a glove factory stock system?

    So the third glove had the thumb in the middle? 

    No, it has a recursive pair of thumbs so it can go both ways (also useful for the multitudes with two thumbs on one hand)    ;)

     Or five, y'know, for those who are all thumbs.
     

  • (cs) in reply to MGS
    Anonymous:
    Phalphalak:
    Anonymous:
    Phalphalak:

    I keep my own java library with useful methods and classes and pair has to proofen to be one of the most usefuls ones. For some geometric algorithms I required to temporarily associate Points with an index. I think it would be inappropriate to especially define a IndexedPoint class for that. Instead I simply used a Pair<Integer,Point>. I think that is a good example of when utilizing such classes makes sense.

    Uh... Any reason why you wouldn't use a HashMap for that? 

     Why should I use a hashmap for two elements? That would result in quite an overhead.
     

     I took your description to indicate that you were working with a set of some kind.  But I guess you were talking about using the 'pair' as an attribute of some object.  Certainly that usage makes sense.
     

    Oh ok, now I get it. Well, the example I gave actually did involve sets of pairs.  Nevertheless, there are probably other sensible examples without sets like the attribute one. Nevertheless, I find it quite convenient to extract a pair from a List<Pair> especially if you when you might need to hold onto some of them.

    In the end its always a comprise between classes serving the role of custom datatypes on one side and wrappers or other helper types on the other. Using Pairs and such exclusively would be backward, of course. I started programming Java long before C++ but discovered that especially pairs were a useful addition as it is quite common to end up in a situation were it would be nice to pair two different values (lets say as a return type for example) without having to create an additional class that is never used elsewhere.

  • (cs) in reply to Island Usurper
    Anonymous:
    jackass:

    You really have to wonder what their class that only deals with two variables is called.

     

    I bet it's "Singleton". 

    And their special container for one item is called a "Nullity". 

  • Vexorian (unregistered) in reply to Mikademus

    I didn't think there was ever the need to return multiple values, What about using reference arguments?

  • (cs)

    It's been a long time since the last CodeSOD.

    Anyway why didn't he just use an array to return more than one value, for example

        public static Object[] Test(){
            return new Object[]{"zarp", 2, 3.1};
        }

     

  • (cs)

    Is someone trying to bring back HyperCard?

  • Ann Coulter (unregistered) in reply to brendan
    Vexorian:

    I didn't think there was ever the need to return multiple values, What about using reference arguments?

     

    I wouldn't say never but if you need to return multiple values then chances are that your function is doing too much or there's a better object you can use for the return value.
     

  • Ded Morris (unregistered) in reply to newfweiler

    I thought they were music fans too.  The first thing I thought of was the King Crimson song "Three of a Perfect Pair"

  • (cs) in reply to jackass
    jackass:

    You really have to wonder what their class that only deals with two variables is called.

    Pair_DEPRECATED_DONOTUSEFORANYREASON_EVER

  • (cs) in reply to Exick
    Anonymous:

    This reminds me of my high school baseball coach who used to tell us to "pair up into groups of 3" and to "circle up in a square".


    Captcha: mustache 

    Better that then your math teacher i guess

  • Dan aka ch0c0 (unregistered) in reply to Pingmaster

    A pair of 3 ?

     

    Thats right up there with my old high school teachers, and "Number (a)," "Number (b)," etc 

    And she was a maths teacher too !
     

  • Eternal Density (unregistered) in reply to KattMan
    KattMan:

    Anonymous:
    So, who's on Second?

    No, Who's on first.

    I don't know.

     

    What do they use for an empty container?  A singularity?

    captcha = genius, as i've been told. 

  • rohcQaH (unregistered) in reply to Mikademus

    Mikademus:
    And their special container for one item is called a "Nullity". 

    exactly. Be careful not to reference an uninitialized container or you might get a MinusOnePointerException.

  • John (unregistered)

    Looks like they grew a pair and now you're jealous.

     

     

     

     

     

    Captcha: wtf (really!)

  • (cs) in reply to Ann Coulter
    Anonymous:
    Vexorian:

    I didn't think there was ever the need to return multiple values, What about using reference arguments?

     

    I wouldn't say never but if you need to return multiple values then chances are that your function is doing too much or there's a better object you can use for the return value.
     

    Also, java doesn't have by-reference passing. The closest you come is the reference-type style of nonprimitives, thus you rely on either an array of one (wtf) or a wrapper class.

    As for why, there's really only a handful of reasons why. In most cases, you can shove the multiple returns into an object (whether of some class or... well... arrays are objects too!). You *could* have the caller pass the array, but that's senseless as it forces the caller to allocate the array - you would only do this for an in/out param - which is exactly the only reason you'd ever need a pass-by-reference. Consider +=, for example. The left-hand argument is in/out (rather than just out for =). Similar logic cannot be achieved without reference parameters. (Granted you can't overload += in java (*grumble grumble*), but you can implement functions that use the same in/out parameter style). As I said above, the only way to do this in java is with a wrapper class (and use 1.5 and generics and save yourself the hassle of casting!) or have the caller pass a single-element array (ICK!).

  • disaster (unregistered)

    Pair eccentrica_galumbits = new Pair();

     

  • disaster (unregistered) in reply to Exick
    Anonymous:

    This reminds me of my high school baseball coach who used to tell us to "pair up into groups of 3" and to "circle up in a square".


    Captcha: mustache 

     Our head of sports, on the other hand, was the kind who would learnedly insist that we use the correct Greek plural for more than one discus. (It was "discoi", or so he said.)
     

  • Ron Pakston (unregistered) in reply to MGS

    Yeah.....choon him broo

  • Marcelloh (from Holland) (unregistered)

    It could actually be a translated class from a foreign language (like dutch).
    We got a pair or a couple; which are the same word in dutch. So by mistake, they only took the wrong translation.

    But what this class does, is a little bit of a mistery to me, since you can actually put everything in that has nothing in common
    with the other 2 objects. (Unless the fact that they are objects). I'm in favour of design by contract.
    Some comment in the class would be nice too.


  • TP (unregistered)

    Of course if you needed to return 3 values using a pair with just two members, you could just nest them:

    return new Pair(first, new Pair(second, third)); 

    Or he could at least have made a new Triplet class that extended Pair.

    Now the real, real WTF is that he didn't implement equals and hashCode so this class could be used in maps :-)

  • (cs) in reply to TP

    I think it's obvious. The 3rd object is the null terminator.

     

  • (cs) in reply to Phalphalak
    Phalphalak:
    Why should I use a hashmap for two elements? That would result in quite an overhead.

    You don't seem overly bothered by the overhead you already have in your snippet:

     

    Phalphalak:

        public String toString() {
            String s = "Pair(";
            s += t + ", " + e + ")";
            return s;
        }
    }

    I'd go with:

        public String toString() {
            return new StringBuffer("Pair(")
            .append(t)
            .append(", ")
            .append(e)
            .append(")")
            .toString();
        } 

     

  • Blame (unregistered)

    This would normally be called ThreeOfAKind, right?

  • (cs) in reply to dmilor
    dmilor:

     

    Phalphalak:

        public String toString() {
            String s = "Pair(";
            s += t + ", " + e + ")";
            return s;
        }
    }

    I'd go with:

        public String toString() {
            return new StringBuffer("Pair(")
            .append(t)
            .append(", ")
            .append(e)
            .append(")")
            .toString();
        } 

     

    I'd rather go with

        public String toString() {
            return "Pair(" + t + ", " + e + ")";
        }

    yours is just to hard to read :), God invented operators for a reason.
  • (cs) in reply to brendan
    brendan:

    I'd rather go with

        public String toString() {
            return "Pair(" + t + ", " + e + ")";
        }

    yours is just to hard to read :), God invented operators for a reason.


     

    Yours is just as inefficient as the code I quoted above i.e. it is exactly the same code just formatted differently. Granted efficiency probably isn't a huge concern in a toString() method but I'd hardly say append().append().toString() is too hard to read. And if it you find it too hard too read then maybe Java isn't for you. ;)


    Further reading on StringBuffer.append() vs String + can be found here. String + stinks. Mightily.

     

  • Matt Turner (unregistered) in reply to v.

    obviously the original author doesn't know Spanish.

  • (cs) in reply to Matt Turner

    I used this code in some super enterprisey software the other day.

    Pair thePair = new Pair(true, new Pair(false, "filenotfound"));

     

     

  • (cs) in reply to dmilor
    dmilor:

    Yours is just as inefficient as the code I quoted above i.e. it is exactly the same code just formatted differently. Granted efficiency probably isn't a huge concern in a toString() method but I'd hardly say append().append().toString() is too hard to read. And if it you find it too hard too read then maybe Java isn't for you. ;)

    WTF.java:

    public class WTF {
        private Object t, e;

        public String toString_brendan() {
            return "Pair(" + t + ", " + e + ")";
        }

        public String toString_dmilor() {
            return new StringBuffer("Pair(")
            .append(t)
            .append(", ")
            .append(e)
            .append(")")
            .toString();
        }
    }

    Output of javap -c WTF (compiled and disassembled with Sun JDK 1.5.0_08):

    Compiled from "WTF.java"
    public class WTF extends java.lang.Object{
    public WTF();
      Code:
       0:    aload_0
       1:    invokespecial    #1; //Method java/lang/Object."<init>":()V
       4:    return

    public java.lang.String toString_brendan();
      Code:
       0:    new    #2; //class java/lang/StringBuilder
       3:    dup
       4:    invokespecial    #3; //Method java/lang/StringBuilder."<init>":()V
       7:    ldc    #4; //String Pair(
       9:    invokevirtual    #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
       12:    aload_0
       13:    getfield    #6; //Field t:Ljava/lang/Object;
       16:    invokevirtual    #7; //Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;
       19:    ldc    #8; //String ,
       21:    invokevirtual    #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
       24:    aload_0
       25:    getfield    #9; //Field e:Ljava/lang/Object;
       28:    invokevirtual    #7; //Method java/lang/StringBuilder.append:(Ljava/lang/Object;)Ljava/lang/StringBuilder;
       31:    ldc    #10; //String )
       33:    invokevirtual    #5; //Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
       36:    invokevirtual    #11; //Method java/lang/StringBuilder.toString:()Ljava/lang/String;
       39:    areturn

    public java.lang.String toString_dmilor();
      Code:
       0:    new    #12; //class java/lang/StringBuffer
       3:    dup
       4:    ldc    #4; //String Pair(
       6:    invokespecial    #13; //Method java/lang/StringBuffer."<init>":(Ljava/lang/String;)V
       9:    aload_0
       10:    getfield    #6; //Field t:Ljava/lang/Object;
       13:    invokevirtual    #14; //Method java/lang/StringBuffer.append:(Ljava/lang/Object;)Ljava/lang/StringBuffer;
       16:    ldc    #8; //String ,
       18:    invokevirtual    #15; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
       21:    aload_0
       22:    getfield    #9; //Field e:Ljava/lang/Object;
       25:    invokevirtual    #14; //Method java/lang/StringBuffer.append:(Ljava/lang/Object;)Ljava/lang/StringBuffer;
       28:    ldc    #10; //String )
       30:    invokevirtual    #15; //Method java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
       33:    invokevirtual    #16; //Method java/lang/StringBuffer.toString:()Ljava/lang/String;
       36:    areturn

    }

    Differences: in brendan's code, the StringBuilder is created empty, then the first fragment is .append()ed.  In dmilor's, the StringBuffer is created with the first fragment, which is probably slightly faster.  On the other hand, StringBuffer is thread-safe whereas StringBuilder is not, so the latter is probably somewhat faster (as claimed by the API docs "under most implementations").  Otherwise, the two generate identical code.

    Even if dmilor's version was changed to use StringBuilder instead, I'm pretty sure (as in, I'm too lazy to test) the difference in speed would be tiny (and that could be eliminated by making the compiler slightly smarter).  All in all, I'd go with the easier-to-read version.

    Of course, in cases that are too complicated for the compiler to optimise this way, using an explict String{Builder,Buffer} will be faster.

  • (cs)

    This cracked me up, since I just last week I had to rewrite a class called 'Pair' to accommodate 3 elements. I too considered not renaming the class - for about a nanosecond.



     

  • bd (unregistered)

    This gives a whole new meaning to pair programming.

  • Daef (unregistered) in reply to bd

    why not build a Pair like:

    class Pair<A,B> {

        private A a=null;
        public A First {
            get{return a;}set { a=value;}
        }

        private B b=null;
        public B Second {
            get{return b;}set {b=value;}
        }

        private Pair<A,B>  nextPair=null;
        public Pair<A,B> NextPair {
             get {
                   return nextPair==null
                        ?(nextPair=new Pair())
                        :nextPair;
              }
             set{nextPair=value;}
        }

        public Pair(A a,B b) {
             this.a=a;this.b=b;
        }

        public Pair() {}
    } 

    Captcha: shizzle

  • (cs) in reply to iwpg
    iwpg:
    Differences: in brendan's code, the StringBuilder is created empty, then the first fragment is .append()ed.  In dmilor's, the StringBuffer is created with the first fragment, which is probably slightly faster.  On the other hand, StringBuffer is thread-safe whereas StringBuilder is not, so the latter is probably somewhat faster (as claimed by the API docs "under most implementations").  Otherwise, the two generate identical code.

    Even if dmilor's version was changed to use StringBuilder instead, I'm pretty sure (as in, I'm too lazy to test) the difference in speed would be tiny (and that could be eliminated by making the compiler slightly smarter).  All in all, I'd go with the easier-to-read version.

    Of course, in cases that are too complicated for the compiler to optimise this way, using an explict String{Builder,Buffer} will be faster.

    I knew I should have put a disclaimer as I stopped coding in Java quite some time ago - certainly before the advent of StringBuilder in Java and more importantly String's implicit use of it - my experience of String is exactly as shown in what I linked. I guess that's what I get for commenting on code in a language that I haven't touched for 18 months or so. :) 

    Re readability: I still think append() makes it very easy to read - in something this small and trivial either way is really easy to read but when it's say a few kb of fragments being concatenated I personally think append() is much easier to read - but that is purely subjective.

    OTOH Mine's still fastest. ;)

     

  • Bob Bane (unregistered)

    I was once called in as a consultant to look over a nearly-written Common Lisp implementation for a CDC machine.  This dinosaur had 60-bit words, and a 20-bit address space (with some sort of funky segmentation on top of it - I forget the details).  Note that this means you could fit three pointers into a word.  So, as an extension, every cons node had three pointers, and you could access them using:CARCDRCCR

  • adolfojp (unregistered) in reply to John Bigboote

    Sir, you just made me lol my pants.

  • (cs)
    Derrick Pallas:

    Some sugary languages allow you to create and return arrays on the fly

    You forgot that other languages also have a completely generic structure that exists exactly for that kind of usages: tuples (or records, which are usually tuples with named items).

    They usually also have some kind of tuple/list unpacking, which means that returning tuples or triples becomes utterly trivial (list unpacking is sorely missing from Javascript by the way, is implemented in JS 1.7 though)

    Note that tuples can only be implemented as immutable lists (ex: Python) when the lists are untyped

Leave a comment on “Three's a Crowd”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article