• Baggy McBagster (unregistered) in reply to Myself

    This looks to me like the work of someone used to Ruby or some other language without useful type checking. People seem to get into the habit of repeatedly forcing variables to the type they want before using them, because they can't just assume the type is correct as a Java or C* programmer would.

    I bet they then go home and feel really pleased about all the time they saved by not having to declare their variable, too :)

  • cthulhu (unregistered)

    the real wtf is the use of "zero" which isnt a real quantity.

  • Rhialto (unregistered) in reply to Zygo
    Zygo:
    When a Java object is passed as an argument, only the pointer that is accessible from the language is passed--the object remains on the heap where it was allocated. We still call this pass-by-value since the pointer value can be modified in the method without affecting the pointer value in the method's caller. If that condition was not met, Java would probably be a pass-by-reference language.

    I agree with most of your explanation. Except here, I'd like to comment that Java pretends to pass the object to the function (because pointers "don't exist"). And because it in reality does pass a pointer, the object can be modified after the function call returns. This violates one of the properties of "pass by value" (the one that says that the thing you pass in can't be modified because it's a copy). So, whatever they say, the effect is like "pass by reference". Purely because they started lying about pointers in the first place.

  • Rhialto (unregistered) in reply to Jackal von ÖRF
    Jackal von ÖRF:
    I've sometimes seen this "have -> of" syndrome in the subtitles on some Asian movies and TV-series. Does anybody here know the origins of that mistake? Does it especially affect some specific language groups?
    In some cases, it is maybe just regional English (and I mean British English), when "should've" is pronounced a bit sloppily and than mis-backtransformed to "should of" instead of "should have".
  • Rotu (unregistered) in reply to Laurence

    That's right, but during conversation, the mind should be active in parsing the words said and actually construct a logical word patterns. I am a psychologist who happens to love programming.

  • Michael (unregistered) in reply to Michael
    Michael:
    ...instead of making everything an object like they did in Ruby.
    And always remembering the Ruby designers decided to "borrow" at least some of the right things from Smalltalk (which the Java designers missed).
  • ralpe (unregistered) in reply to Tom

    The only thing I can really think of is an overreaction to Java's aliasing. By default, everything is passed by reference, so if you're not careful, you can get some really weird side effects. Could be that they're just going overboard on making copies.

    Only objects are passed by reference. Primitives types are passed by value.

  • Asd (unregistered) in reply to GeneWitch
    Let X represent an object. X takes up 16K of memory. What does java do when you pass X into a function? It copies the 16K object. The computer has access to this 16K of memory's start address, which is an arbitrary length value, say 4 bytes.

    If you pass by Reference, you are passing the 4 bytes to the function.

    If you pass by Value, you are passing the 16K Object (meaning it gets recreated at another 4 byte memory location, and is now referenced there).

    There's a damn reason that in C++ the int &X thing is there...

    • = dereference & = reference.

    /sigh.

    Nope. String s = "foo"; Now the value of s is your 4 byte reference to the actual ~30 byte object.

    So when you call doSomething(s) the 4 byte reference is copied to the stack. That is pass by value.

    If you are using a primitive:

    long l = 0L; Now the value of l is your 8 byte long. When you call doSomething(l) the 8 bytes are copied to the stack. Also pass by value.

    Also it is possible to mess with immutable objects using reflection: http://javaspecialists.co.za/archive/newsletter.do?issue=014&locale=en_US

  • java (unregistered) in reply to Trondster
    Trondster:
    Well - for the first way to call someMethod, you surely mean:

    int x = 0; someMethod(x);

    or

    Integer x = new Integer(0); someMethod(x);

    boggles

    1.5 has autoboxing. The second should be Integer x = Integer.valueOf( 0 ); The "x" can be pooled. :)

  • paula (unregistered) in reply to Tom
    Tom:
    The only thing I can really think of is an overreaction to Java's aliasing. By default, everything is passed by reference, so if you're not careful, you can get some really weird side effects. Could be that they're just going overboard on making copies.

    They probably call it a 'design pattern'.

    GOD NO! NOTHING nothing nothing is "passed by reference".

    Everything is "passed by value". Primitives are "passed by value". Reference Types are "passed by value". Objects are NEVER EVER EVER passsed.

  • clueless (unregistered) in reply to teacher
    teacher:
    Scotty:
    Marcin:
    Possibly the result of copy-and-paste from code where the programmer was worried that the Integer object might be modified (if so, that's another WTF, of course).
    Integer objects are immutable. It is not possible to modify the value of the primitive stored inside the object. Of course the programmer probably didn't know that...
    Not possible? Pishaw! You, Sir, have not yet discovered the wonders of JNI...

    One of my former coworkers (an extremely bright and talented programmer) was absolutely certain that, as you state, it was not possible to change the value of an immutable object. I wrote a very short program using JNI to get at the underlying bytes, and changed the value of a String from Hello to World. Without having seen the code, it took him quite a while to figure out how I was able to do it.

    You don't need JNI, Reflection is all you need.

  • (cs) in reply to mpd
    mpd:
    For object-oriented languages, such as Java, there's some reason for having classes such as Integer and Boolean - mostly for storing those values in lists, trees, etc. that take Objects as arguments.
    While there are reasons for having both primitive and wrapped types in the language, there is no damn reason whatsoever to make them visible to the langage's user.
    mpd:
    Starting with version 5 (I believe), Java performs auto-boxing which performs automatic wrapping of native data types when necessary.
    Nope, it performs automatic boxing of native datatypes when it feels compelled to, and if it's easy enough: it will autobox a primitive value in and out of a collection, but not much more. C#, on the other hand, boxes and unboxes primitive value every time it's needed, you can call a method on a "primitive" type and C# will just box it in the corresponding wrapper type.

    That's what most languages do, too, the interface is completely uniform and you don't know nor care whether you're manipulating primitive or wrapped values.

    Nor should you.

    Michael:
    This is a hack because of the original decision to use primitives in Java, instead of making everything an object like they did in Ruby.
    The issue isn't that they used primitive types instead of making everything an object (primitive types are sensible in optimization contexts), the issue is that they didn't make everything look like objects. Python and Ruby only manipulate objects, but C# (for instance) uses primitive types, it just boxes and unboxes them so that you can't tell them apart from regular objects (unless you read the IL code)
    Reed:
    "Java is always Pass-By-Value. The confusion is from the fact that when passing an object, it is the objects reference that is being passed by value." ~Tim

    And that's called.... "Pass by reference"....

    No, that's called "pass reference by value", "pass by reference" is usually understood with C++' semantics, which aren't even remotely close to Java's (and most reference-using langage) semantics.

    savar:
    I don't see any problem with it. Sometimes you want a primtive, opaque value. Sometimes you want an object. Java 5 autoboxes, so that interconverting between the two representations is syntactically simplified.
    Do you, really? I don't, I just want stuff to get done, and the primitive/boxed dichotomy is just a retarded annoyance, I don't give a damn about what happens under the hood, but I care about having to actively think about whether I want a primitive or a wrapped datatype. i shouldn't have to.
    sf:
    Michael:
    richard:
    just a humble question from a non-java coder: why not just call someMethod(0); ? Ok, if it was an option, it would surely have been mentioned, i just want to know why, thx!

    Because in Java, an "int" and an "Integer" are different data types. "int" is a primitive while "Integer" is an object. If someMethod was defined as:

    someMethod(Integer i) or someMethod(Object o)

    then passing an "int" would cause a compile time error in Java 1.4 and older. However, as mentioned already, Java 1.5 and up have auto-boxing, which will convert an "int" to an "Integer" and back when needed.

    This is a hack because of the original decision to use primitives in Java, instead of making everything an object like they did in Ruby.

    Or like it was done in Smalltalk (my first OO love) nearly 30 years before Ruby.

    And how it's done in pretty much every language ever since. Except Java.

    Baggy McBagster:
    This looks to me like the work of someone used to Ruby or some other language without useful type checking. People seem to get into the habit of repeatedly forcing variables to the type they want before using them, because they can't just assume the type is correct as a Java or C* programmer would.

    I bet they then go home and feel really pleased about all the time they saved by not having to declare their variable, too :)

    Congratulation. You, sir, are an idiot. And you've never worked with a dynamically, strongly typed language (Smalltalk, Python, Ruby, Scheme, Erlang, you name it)

  • Sezerp (unregistered) in reply to Rhialto
    Rhialto:
    Zygo:
    When a Java object is passed as an argument, only the pointer that is accessible from the language is passed--the object remains on the heap where it was allocated. We still call this pass-by-value since the pointer value can be modified in the method without affecting the pointer value in the method's caller. If that condition was not met, Java would probably be a pass-by-reference language.

    I agree with most of your explanation. Except here, I'd like to comment that Java pretends to pass the object to the function (because pointers "don't exist"). And because it in reality does pass a pointer, the object can be modified after the function call returns. This violates one of the properties of "pass by value" (the one that says that the thing you pass in can't be modified because it's a copy). So, whatever they say, the effect is like "pass by reference". Purely because they started lying about pointers in the first place.

    Your logic is flawed. You assume that the statement: String s = "blah"; defines s as 'object of type String'. In fact it doesn't, it defines s as 'reference to object of type String'. In this sense Java has pointers. Here's what Java Language Specification has to say about it:

    "4.1 The Kinds of Types and Values There are two kinds of types in the Java programming language: primitive types (§4.2) and reference types (§4.3)."

    See? There are no 'object variables' in C++ sense. Now, let's see what happens when you call a method - JLS again:

    "When the method or constructor is invoked (§15.12), the values of the actual argument expressions initialize newly created parameter variables, each of the declared Type, before execution of the body of the method or constructor."

    Which sound hell a lot like 'passing by value' to me... And if you don't agree with JLS - well, it's no more Java then.

  • SomebodyElse (unregistered) in reply to clueless
    clueless:
    teacher:
    Scotty:
    Marcin:
    Possibly the result of copy-and-paste from code where the programmer was worried that the Integer object might be modified (if so, that's another WTF, of course).
    Integer objects are immutable. It is not possible to modify the value of the primitive stored inside the object. Of course the programmer probably didn't know that...
    Not possible? Pishaw! You, Sir, have not yet discovered the wonders of JNI...

    One of my former coworkers (an extremely bright and talented programmer) was absolutely certain that, as you state, it was not possible to change the value of an immutable object. I wrote a very short program using JNI to get at the underlying bytes, and changed the value of a String from Hello to World. Without having seen the code, it took him quite a while to figure out how I was able to do it.

    You don't need JNI, Reflection is all you need.

    And to prove the point that reflection will work, here is the voodoo.

    class Test {
    
    	    public static void main(String[] args) throws Exception {
    	        Integer i = new Integer(0);
    	        System.out.println("I before change is:" + i);
    	        change(i);
    	        System.out.println("I after change is:" + i);
    	    }
    	 
    	    static void change(Integer i) throws Exception {
    	        Class cls = Integer.class;
    	        Field field = cls.getDeclaredField("value");
    	        field.setAccessible(true);
    	 
    	        Integer newValue = new Integer(1 + i.intValue());
    	        field.set(i, newValue);
    	    }
    
    
    
    }
    
  • anon (unregistered)

    Well...

    String a = new String(String.valueOf("a"));

  • laowai (unregistered) in reply to Earl Purple
    Earl Purple:
    It's not just offshoring I object to, I object if a company I work for contracts out development work to any other company because there seems to be some automatic assumption that such developers are far more "expert" than anyone they might have in the company.

    Often it's not more "expert", only more "cheap". And since business is all about the bottom line, they go for it.

  • Anonymous Coward (unregistered) in reply to Natrone

    better make it: someMethod(Integer.valueOf(0).intValue());

    ;)

  • sf (unregistered) in reply to SomebodyElse
    SomebodyElse:
    clueless:
    teacher:
    Scotty:
    Marcin:
    <snip>
    <snip>
    Not possible? Pishaw! You, Sir, have not yet discovered the wonders of JNI... <snip>

    You don't need JNI, Reflection is all you need.

    And to prove the point that reflection will work, here is the voodoo.

    class Test {
    
    	    public static void main(String[] args) throws Exception {
    	        Integer i = new Integer(0);
    	        System.out.println("I before change is:" + i);
    	        change(i);
    	        System.out.println("I after change is:" + i);
    	    }
    	 
    	    static void change(Integer i) throws Exception {
    	        Class cls = Integer.class;
    	        Field field = cls.getDeclaredField("value");
    	        field.setAccessible(true);
    	 
    	        Integer newValue = new Integer(1 + i.intValue());
    	        field.set(i, newValue);
    	    }
    
    
    
    }
    

    Not only can you do it with reflection (assuming you have security rights) you can screw up your JVM state with it. If you do this: [code] Integer i = Integer.valueOf(0); java.lang.reflect.Field f = Integer.class.getDeclaredField("value"); f.setAccessible(true); f.setInt(i, 42); [code] Now all subsequent calls to get a 0 Integer value using [code]Integer.valueOf(0)[code] will give you one with the value of 42.

  • TimHill (unregistered) in reply to GoatCheez

    This boxing/unboxing thing exists because languages like Java and C# try to straddle the space between C/C++ and script languages like Ruby/Python. The "primitive" types exist mainly for efficiency; a JIT can handle most primitives directly in CPU registers (fast), whereas a boxed type needs to be handled via a pointer (reference), which is slower. Similarly, boxed types are allocated on the heap and incur GC overhead, while primitives can move directly from the stack to registers etc.

    Boxing is necessary to allow the primitives to be "object-like" when they need to act polymorphically (e.g. in collections). Additionally, boxing primitives provides a nice parking-place for all the type-related methods to live.

    Languages like Ruby are much cleaner in that all types are objects, but they pay a significant performance penalty.

  • Grogs (unregistered) in reply to Orson

    Totally!

  • Prove that you're not a robot (unregistered) in reply to sf

    That's a great way to drive someone mad !

  • Garrett (unregistered) in reply to Tom

    OK, I had to put my 2 cents in, Java has no pass by reference, it's all pass by value

  • FuBar Revisited (unregistered)

    This programmer is definitely wearing MAGIC PANTS.

    I think it needs at least 3 more layers of boxing and unboxing to be properly obfuscated.

  • Garrett (unregistered) in reply to GeneWitch
    GeneWitch:
    Let X represent an object. X takes up 16K of memory. What does java do when you pass X into a function? It copies the 16K object. The computer has access to this 16K of memory's start address, which is an arbitrary length value, say 4 bytes.

    If you pass by Reference, you are passing the 4 bytes to the function.

    If you pass by Value, you are passing the 16K Object (meaning it gets recreated at another 4 byte memory location, and is now referenced there).

    There's a damn reason that in C++ the int &X thing is there...

    • = dereference & = reference.

    /sigh.

    Java will NOT pass the 16K Object. The confusion has been explained several times in here, but I will try to explain it again.

    The terms "Pass-by-value" and "Pass-by-reference" are talking about the actual variable, not the data. When you pass the variable's value, it's called "Pass-by-value", when you pass the variables reference, it's called "Pass-by-reference". The confusion is that a value of a variable can be a reference, but you are still pass the value of the variable, not the reference of the variable. In java, you cannot access the reference of a variable (outside of JNI that is).

  • Vincent (unregistered) in reply to Pat

    In VBScript you can just go

    " someMethod 0 "

  • ngist (unregistered)

    I was talking to one of the developers I was interning with and he told me about a friend of his who lost his work visa after he got laid off and had to go back to India. He heard from the guy a few months latter. He was basically in a coding sweatshop, lined up in a row with 20 other "programmers".

    They were being paid by how many lines of code they wrote, so if you could take a 5 line function and turn it into a 50 line function you did.

    This is probably one reaon why so much code outsourced offshore is so bad.

  • Micro Progammer (unregistered) in reply to Baggy McBagster

    From my perspective strict type checking is not necessary in all cases - but is useful where it makes sense.

    Python is a good example of the perfect compromise. As long as the result of the operation makes sense, python allows it.

    So you could add a float and an integer, and get a perfectly acceptable result because python has built-in rules for arithmetic type conversions:

    >>> x=1.3
    >>> y=1
    >>> z=x+y
    >>> z
    2.2999999999999998
    >>> 

    Of course, you could coerce the result to an integer if you wanted:

    >>> z=int(x+y)
    >>> z
    2

    Where it doesn't make sense, python raises an exception:

    >>> x="hello"
    >>> z=int(x+y)
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    TypeError: cannot concatenate 'str' and 'int' objects

    In a string context, python assumes you want to concatentate the strings with the '+' operator...but it can't do that, unless you explicity force the integer to be a string:

    >>> z=x+str(y)
    >>> z
    'hello1'

    Furthermore you can use the 'isinstance' function - which returns a boolean value to test the item's type, typically used to allow functions to do different things depending upon the type passed:

    def delete(mylist, item):
        if isinstance(item, int):
           del mylist[item]
        else:
           mylist.remove(item)

    How is this any different than overloading type conversion operators in C++ to do the same thing? Not much, other than semantics.

    I would argue you have to be a smarter programmer to use python - you have to understand how the virtual machine is going to coerce your types - and act selectively. Now, I have seen python code like this before also:

    >>> x="hello"
    >>> y="yello"
    >>> z=str(str(x)+str(y))
    >>> z
    'helloyello'
    

    While this works, it is clearly overkill. a simple z=x+y would have sufficed. This is clearly a case of cargo-cult programming because the developer does not have a clear understanding of types. We can clearly see that x and y were assigned as strings - so no need to coerce them. On the other hand, if we expect to get our data from an unknown source (such as a human being - notorious for providing unanticipated input), we would instead use our isinstance function to verify the input:

    if isinstance(x, str) and isinstance(y, str):
        z=x+y
        print z
    else:
        print "sorry, try again!"

    This is where test-based programming comes into play - to assert a particular state - and raise and handle the exception when it is not - we could do this more elaborately to interact with automated testing. I guess the bottom line is - know your tools well, or look like a fool (probably should be the motto of WTF?!).

  • bbb (unregistered) in reply to sir_flexalot

    Just Another Virtualisation Architecture

  • iw (unregistered)

    This entire conversation alone has me completely convinced that Java sucks.

  • Java Coward (unregistered)

    What non-Java folks need to know is that primitives and Objects are fundamentally different in Java. If you need a parameter or result that is an object, it must derive from the Object Class, which primitives don't. Normally what drives this is the need to fit a primitive into a method signature that requires an object, hence you wrap it. if you need to concatenate the value into a string, say for a log statement, you can unwrap it. And yes, it is freaking tedious. Our friend in this case is just like to exercise his int's and Integer's.

    Actually this is unnecessary due to the "Autoboxing" feature starting in Tiger, jdk 1.5.0

  • Anonymous (unregistered) in reply to Scotty
    Scotty:
    Er... isn't a "pointer to the object" the definition of a "reference"? As in "pass by reference"?
    No, you're wrong! The difference between "pass by value", "pass by reference", "pass by name" (which some very obsolete languages use, and is very error-prone) are concerned about the semantics of variables/parameters used on the left side of the assignment operator. It has to do with the concepts of 'l-value' and 'r-value'.

    As C++ has both "pass by reference" and "pass by pointer" (besides "pass by value"), it's easy to demonstrate the difference using C++:

    #include <iostream>
    
    using namespace std;
    
    static void pass_by_reference(int &x) {
      x = 4;
    }
    
    static const int four = 4;
    static void pass_by_pointer(const int *x) {
      x = &four;
    }
    
    
    
    int main() {
      int a = 2;
      int b = 2;
    
      pass_by_reference(a);
      pass_by_pointer(&b);
    
      cout << a << endl;
      cout << b << endl;
    
      return 0;
    }
    

    Compile and run this simple program, and you'll get:

    4
    2
    

    I leave it as an exercise to you to figure out why. :)

  • Anonymous (unregistered) in reply to GeneWitch
    GeneWitch:
    Let X represent an object. X takes up 16K of memory. What does java do when you pass X into a function? It copies the 16K object.
    No, you're wrong. Java only passes the pointer to object X to the callee.
    GeneWitch:
    There's a damn reason that in C++ the int &X thing is there...
    • = dereference & = reference.

    Only half of the story. Indeed, "*" and "&" are both overloaded, and hence can be confusing. Actually, the declaration "int *x" is parsed as {{int } x} while "int &x" is parsed as {{int &} x}. The spacing is irrelevant here. Although many people like to write "&" and "" together with the identifier "x", that doen't change how the C++ parser handles the declaration.

    When used as type modifiers as in the above declarations, "&" means reference and "" means pointer. However, these 2 symbols are also unary operators on variables, in which case "&" means "the address of" and "" means "deference".

    Let's not dig into .* and ->* operators... :)

  • Schabi (unregistered) in reply to Sezerp
    Sezerp:
    Well, it doesn't :( Try this:

    public static void main(String[] args) { Integer a = new Integer(0); Integer b = new Integer(0);
    System.out.println( (a==b) ); } ..and you'll get 'false'.

    It must give 'false' here, because you explicitly create two different instances using the new operator. All other means of producing the Integer objects (autoboxing, Integer.valueOf() etc.) may happily reproduce the same instance.

  • Peter Lawrey (unregistered) in reply to java

    There is a fixed pool size of Byte, Short, Integer, Long and Character. See X.valueOf(primative)

    I have seen a long list of the following x.getClass() == new Integer(0).getClass() x.getClass() == new Double(0.0).getClass() ...

    even x.getClass() == new String("").getClass()

  • (unregistered) in reply to Prove that you're not a robot

    [quote user="Prove that you're not a robot"]That's a great way to drive someone mad ![/quote]

  • (unregistered) in reply to Prove that you're not a robot

    [quote user="Prove that you're not a robot"]That's a great way to drive someone mad ![/quote]

  • dube (unregistered)

    Our application also contains such entertaining code like

    String emptyString = new String("");
    String myString = new String(emptyString);
  • (cs) in reply to Anonymous
    Anonymous:
    Scotty:
    Er... isn't a "pointer to the object" the definition of a "reference"? As in "pass by reference"?
    No, you're wrong! The difference between "pass by value", "pass by reference", "pass by name" (which some very obsolete languages use, and is very error-prone) are concerned about the semantics of variables/parameters used on the left side of the assignment operator. It has to do with the concepts of 'l-value' and 'r-value'.

    As C++ has both "pass by reference" and "pass by pointer" (besides "pass by value"), it's easy to demonstrate the difference using C++:

    #include <iostream>
    
    using namespace std;
    
    static void pass_by_reference(int &x) {
      x = 4;
    }
    
    static const int four = 4;
    static void pass_by_pointer(const int *x) {
      x = &four;
    }
    
    
    
    int main() {
      int a = 2;
      int b = 2;
    
      pass_by_reference(a);
      pass_by_pointer(&b);
    
      cout << a << endl;
      cout << b << endl;
    
      return 0;
    }
    

    Compile and run this simple program, and you'll get:

    4
    2
    

    I leave it as an exercise to you to figure out why. :)

    Uh, because pass by reference is meant to explicitly edit the information at a memory address, and pass by value (or ptr) is meant to use but not edit the information at a memory address.

    I know that java doesn't have pointers, i was merely explaining WTF byval and byref did. In one you're getting a pointer to the memory location, and in the other you're not.

  • ELIZA (unregistered)

    Wouldn't it be simpler to call SomeMethod(0)

  • cheap jerseys (unregistered)

    cheap NFL JerseyLewis says the Magic knew they could beat the Cavaliers in the Eastern Conference Finals when the the two teams cheap kobe jerseymet for Game 2. cheap Paul Smith Shoes It took a miracle shot from LeBron James to beat Orlando cheap nfl jerseys cheap nfl jerseys Bucks are looking very closely at every point guard available in the draft would make you cheap g star think Sessions replica jerseys walk, but it's far replica NFL jerseys, NHL jerseys too early to know. In truth, the Bucks nfl jerseysthemselves haven't f teams are starting to think about what cheap diesel Villanueva would look like in their nba jerseysuniforms. One of them might be the Cleveland Cavaliers. cheap NFL Jersey mlb jerseys cheap nfl jerseys James' no-show after Game 6, we're finally getting down to business. Dwight Howard nfl jerseys and Kobe Bryant will lace them up o decide cheap uggsthe best team in cheap north face jacketthe NBA. The Magic swept the season cheap jerseysseries from the Lakers, one of that feat (Charlotte was the other) cheap nhl jersey Raptors are they'd cheap tommy bahama also like to another selection there. With teams like L.A., Chicago, and Minnesota cheap nhl jersey selling that area, they're replica NFL jerseys, NHL jerseys likely to find someone they can work with.cheap nba jersey Portland, Houston failed to shifts lebron james jersey back to Houston for Game 6 on Thursday as the Rockets scurry to make Jordan jerseys adjustments cheap nhl jerseys of the Blazers cheap ugg boots Grizzlies, and it's been mentioned that that pick could be had as well. Most teams looking to buy in are looking to buy into cheap ugg bootsthe late first/early second round. Memphis has picks potentially available in both those areas.cheap mlb jerseys Timberwolves use all three of their first round picks this year (6-18-28), and while it's all but certain they'll use cheap true religion jeanstheir #6 pick and probably the #18, that #28 could absolutely be had. For teams looking to buy into that part of the draft (see below), the Wolves cheap nhl jerseys

Leave a comment on “Primitive Wrapping and Unwrapping”

Log In or post as a guest

Replying to comment #:

« Return to Article