• Natrone (unregistered)

    The only thing that would make this believable is with a setObject (object) method.  This would be a java hack to get "pointers."  But alas, this method does not exist, so.... HAHAHAHA

  • Jesse Wilson (unregistered)

    This could be used to hide methods inherited from Object, such as toString(), equals() and hashCode(). For example, are you having problems using the same key multiple times in a HashMap? Then wrap it with ObjectWrapper!

  • (cs)

    This thing's transmogriffic, has chris discovered what the hell went through the head of the guy who ... discovered this?

  • Pint (unregistered)

    this is not ready. i would add a method do recursively get the deep inside object in case someone wraps a wrapper inside the wrapper.

  • (cs) in reply to Jesse Wilson
    Anonymous:
    This could be used to hide methods inherited from Object, such as toString(), equals() and hashCode(). For example, are you having problems using the same key multiple times in a HashMap? Then wrap it with ObjectWrapper!

    the wrapper class would have all those functions inherited from java.lang.Object so I don't quite follow what your saying... unless of course your joking.
  • cdn (unregistered) in reply to tster
    tster:
    Anonymous:
    This could be used to hide methods inherited from Object, such as toString(), equals() and hashCode(). For example, are you having problems using the same key multiple times in a HashMap? Then wrap it with ObjectWrapper!

    the wrapper class would have all those functions inherited from java.lang.Object so I don't quite follow what your saying... unless of course your joking.


    Yes, but those methods would be called on the ObjectWrapper instance, not the object it wraps. For example:
    String s = "Brillant";
    ObjectWrapper o1 = new ObjectWrapper(s);
    ObjectWrapper o2 = new ObjectWrapper(s);
    o1.equals(o2); // false

  • Derek (unregistered)

    Believe it or not, I've actually had to implement something like this before. In WebLogic, when you store something in the session, if the value you store implements Serializable, it insists on serializing it to store it, which wastes memory and CPU, and breaks the "==" comparison, and is unnecessary if you're not clustering the sessions. We created a stupid (non-Serializable) wrapper class basically exactly as above so that we could store a particular Serializable object in the session without those problems.

  • (cs) in reply to tster
    tster:
    Anonymous:
    This could be used to hide methods inherited from Object, such as toString(), equals() and hashCode(). For example, are you having problems using the same key multiple times in a HashMap? Then wrap it with ObjectWrapper!

    the wrapper class would have all those functions inherited from java.lang.Object so I don't quite follow what your saying... unless of course your joking.


    For a site where the users so often reply humorously or sarcasticly (or are trolling), it's amazing how much stuff is taken seriously.
  • (cs)
    Alex Papadimoulis:

    [image]Since a good portion of readers are out enjoying the last day of their three-day Memorial-Day weekend, I thought today would be a perfect opportunity to rehash the ObjectWrapper. It's a Java class that almost made it into Chris' company's codebase as a check-in (and no, not as a joke). It's become a bit of a cult phenomena around the office and even inspired creativity in one of the developers as the thumbnail aside shows ...

    public class ObjectWrapper
    {
       private <FONT color=#0000ff>Object</FONT> <FONT color=#000000>object</FONT>;
       public ObjectWrapper(<FONT color=#0000ff>Object</FONT> <FONT color=#000000>object</FONT>)
       {
          this.<FONT color=#000000>object</FONT> = <FONT color=#000000>object</FONT>;
       }
       public <FONT color=#0000ff>Object</FONT> getObject()
       {
          return <FONT color=#000000>object</FONT>;
       }
    }

    Object object? Object object object!!! Object... WTF?

    >BiggBru

  • (cs)

    WTF? I was still editing my post, you ~#~€~#€#€ forum software. how you dare timeout me? Never mind, I have bolded out the new parts (poor man's post edit)

    (moderator's note: I've deleted the old post)

    I find this funny because it's the natural conclusion of the OOP principle of hiding eveything behind abstractions. If you take this principle too seriously, you wind up with layers over layers of abstraction. And then some more layers to abstract the abstraction.

    And then you'll eventually need to use the objects from a different point of view because of Murphy's Law. And then, of course, you'll need to create a brand new abstraction, because the old object has gotten so abstracted that you can't get it to behave diferently from what it was intended to under the first abstraction.

    Then you have two abstractions over the same object, which have to be kept in sync, because every time to change the underlying object, you risk breaking both abstractions. We won't even mention the pitfalls of using inheritance for "making abstraction easier".

    Then a new use for your object emerges, and you need a third abstraction.....

    Eventually the abstractions get so messy that you get afraid of touching them, on fear of causing accidentally an abstractional paradox that sucks your brain dry :)

  • awefawfawfwafe (unregistered) in reply to BiggBru

    Brain!  Brain!  What is Brain!

  • (cs)

    I have always liked the creative use of templates. What about an ObjectWrapper to wrap any random class as an object? This way you can create an array of ObjectWrapper and store anything on them! A implementation of void* on Java!

    
public class ObjectWrapper<T> 
{
   private <T> object;
   public ObjectWrapper(<T> object)
   {
       this.object = object;   
   }   
   public Object getObject()   
   {
       return (Object)object;
   }
   public <T> getT()   
   {
       return object;
   }
}
  • Eq (unregistered) in reply to awefawfawfwafe

    Oh my. That's the same kind of thinking that would implement a BASIC interpreter in BASIC. I wonder what he thought it was for, and whether "generics" came into it.

    P.S. I'm duty-bound as a language pedant to point out that "phenomena" is plural. One of them is "a phenomenon".

  • (cs) in reply to Enric Naval
    Enric Naval:
    I find this funny because it's the natural conclusion of the OOP principle of hiding eveything behind abstractions. If you take this principle too seriously, you wind up with layers over layers of abstraction. And then some more layers to abstract the abstraction.

    Abstraction isn't just an OOP principle.  OOP is just a technique for constructing abstractions.  Anyway, it's kind of a given that you only want to create useful abstractions depending on the problem to be solved.  If a layer of abstraction serves no purpose, I don't know of any technique (OOP or otherwise) that necessitates it.
  • shmoopy (unregistered)

    Having such a class can be for a number of reasons: storing duplicates of objects in a hash, abstracting the object's class charastaristics (e.g., if a piece of code somewhere does 'if (o instanceof I)...') etc.

    I can imagine a situation in a large company where there will be a dark corner somewhere where this is needed.

  • (cs)

    Since anonymous inner classes cannot modify local variables, this could actually be useful in some situations if it had a setObject method:

    public Object getSomeObject() {
    final ObjectWrapper objw = new ObjectWrapper();

    ObjectListener listener = new ObjectListener() {
        public void hereItIs(Object o) {
            objw.setObject(o);
        }
    };

    foo.runListener(listener);

    return objw.getObject();
}

    Of course, it could also be done like this:

    public Object getSomeObject() {
    final Object[] obja = new Object[1];

    ObjectListener listener = new ObjectListener() {
        public void hereItIs(Object o) {
            obja[0] = o;
        }
    };

    foo.runListener(listener);

    return obja[0];
}
  • Brent (unregistered) in reply to shmoopy

    No, none of those reasons are valid.
    1) Storing duplicates of objects?  It's not a duplicate; the original object hasn't been cloned.  It's just inside of this object.
    2) So you're saying that maybe there's a line in the code saying if (o instance of ObjectWrapper) ?  That's effectively saying if (o instance of Object), which is effictively saying if (true).  Rewrite that code.

    There's no possible reasonable use for this paradigm in Java.

    - B

  • Mig-O (unregistered) 
    <font face="Tahoma">Assuming this is java you could much better use Templates to avoid neccessary Casts to the original Object Type.</font>

    public     class ObjectWrapper<T extends Object>
    {
       private <font color="#0000ff">T</font> <font color="#000000">object</font>;
       public ObjectWrapper(T <font color="#000000">object</font>)
       {
          this.<font color="#000000">object</font> = <font color="#000000">object</font>;
       }
       public <font color="#0000ff">T</font> getObject()
       {
          return <font color="#000000">object</font>;
       }
    }
    <font face="Tahoma">
    By doing it this way you can easyly wrap anything up like:</font>

    ObjectWrapper<SomeWairdClassName> wrappy = 
        new ObjectWrapper<SomeWairdClassName>(SomeWairdClassInstance);


  • (cs)

    Uhh ... WTF?

    I mean, most people who code WTFs just learn the absolute mini. of a language to make some cobbled together POS software, but this has absolutely no value - it doesn't even doing anything at all! This is either a joke, or some programmer out there should be shot.

  • missing (unregistered)

    What Im mostly afraid of is, that so many people have mentioned ideas of possible legal use of this within Java... I can hardly remember any other wtf with similar characteristics...

  • Scott (unregistered)

    This is half way to using the decorator pattern....  on the Object class.

  • Mike M (unregistered)

    The Java mapping for CORBA uses "holder" objects for out and inout parameters, since Java uses pass-by-value inherently, even for reference objects. It's weird. So, of course, there is ObjectHolder. Admittedly, it's a bit more complex than ObjectWrapper, but mostly for living in a CORBA world.

    I think there might be a better way to do this, using classes that are designed to be treated as out and inout parameters, since most are anyway. I guess the CORBA folks assumed that everyone uses overly general idl2java-style tools, instead of something more problem-specific.

  • Tei (unregistered) in reply to Scott

    This is not a WTF, only ugly and bad code.

    The real WTF can be to use a wrapper objet to avoid modified a global object.

    .
    .
    //save a copy of currentScreen to avoid changes
    screen = new Screen( currentScreen );

    //may or may not damage currentScreen
    DangerousFunction();

    //restore
    currentScreen = screen;
    .
    .

    --Tei

  • (cs) in reply to Mig-O
    Anonymous:
    <FONT face=Tahoma>Assuming this is java you could much better use Templates to avoid neccessary Casts to the original Object Type.</FONT>

    public     class ObjectWrapper<T extends Object>
    {
       private <FONT color=#0000ff>T</FONT> <FONT color=#000000>object</FONT>;
       public ObjectWrapper(T <FONT color=#000000>object</FONT>)
       {
          this.<FONT color=#000000>object</FONT> = <FONT color=#000000>object</FONT>;
       }
       public <FONT color=#0000ff>T</FONT> getObject()
       {
          return <FONT color=#000000>object</FONT>;
       }
    }
    <FONT face=Tahoma>
    By doing it this way you can easyly wrap anything up like:</FONT>

    ObjectWrapper<SomeWairdClassName> wrappy = 
        new ObjectWrapper<SomeWairdClassName>(SomeWairdClassInstance);


    This code has the problem that it may actually serve a useful purpose, so it wouldn't be a wtf :)

    The unnecessary cast to object was there because I was trying to follow the trend on the original wtf. Imagine using a trick creating a ObjectWrapper array storing templated ObjectWrapper objects inside. You could then treat them as generic objects or as the original class, as you wanted!

    //there may be syntax errors
    

    //we wrap correctly three objects
    

    ObjectWrapper<Integer> o1 = new ObjectWrapper<Integer>(new Integer(15));
ObjectWrapper<String> o2 = new ObjectWrapper<String>(new String("15"));
ObjectWrapper<Double> o3 = new ObjectWrapper<Double>(new Double(15.0));
    

    // we create an array to store them all
// we cast them all to the same class
    

    new Vector<ObjectWrapper> wtf = new Vector<ObjectWrapper>;
wtf.add((ObjectWrapper)o1);
wtf.add((ObjectWrapper)o2);
wtf.add((ObjectWrapper)o3);
    

    //now I can parse the vector and call getObject on all of them!
//and I can still use getT and get the original object with no class!
for ( int i = 0; i < wtf.size(); i++ ) {
doSomethingWithAnObject(wtf.get(i).getObject());
println(wtf.get(i).getT().getClass()); //prints "Integer", "String", "Double"
}

    so..... why not just use getT and cast to Object? Because this is the dailywtf :)

  • (cs) in reply to Natrone
    Anonymous:
    The only thing that would make this believable is with a setObject (object) method.  This would be a java hack to get "pointers."  But alas, this method does not exist, so.... HAHAHAHA


    Thr real WTF is: this would be a duplication of the org.omg.CORBA.ObjectHolder class. (The other real wtf is the "omg" package.)
  • Simon (unregistered)

    I Object!

  • plizak (unregistered)

    Our soceity is going to ruin this earth with our excessive packaging!

  • (cs) in reply to Chris F
    Chris F:
    Enric Naval:
    I find this funny because it's the natural conclusion of the OOP principle of hiding eveything behind abstractions. If you take this principle too seriously, you wind up with layers over layers of abstraction. And then some more layers to abstract the abstraction.

    Abstraction isn't just an OOP principle.  OOP is just a technique for constructing abstractions.  Anyway, it's kind of a given that you only want to create useful abstractions depending on the problem to be solved.  If a layer of abstraction serves no purpose, I don't know of any technique (OOP or otherwise) that necessitates it.


    Actually, OOP declares that abstractions should only be applied if they have some real world sense and never for sole technical purpose.

    So what does this ObjectWrapper tell about the author's world? He/she must think of all perceptual input as just another layer to hide reality. It's basically a pessimistic version of the Platonic principle: where all the ideas are wrapped in infinite layers of delusions unreachable by the human mind.

    Or in a less pessimistic interpretation this is the world of a Buddhist, where the constant and stubborn repetition of the ".getObject()" mantra eventually leads you to the core of the truths: public class Nirvana.
  • Looce (unregistered) in reply to plizak
    Anonymous:

    Our soceity is going to ruin this earth with our excessive packaging!

    <FONT face="Courier New" size=2>public class PlasticObjectWrapper extends ObjectWrapper
    </FONT><FONT face="Courier New" size=2>{
    </FONT><FONT face="Courier New" size=2>}</FONT>

    Captcha = enterprisey

  • Mellon (unregistered)

    Could it be more usefull to add some more attributes to the class? such as an expiration time/date? Saying, the object is only valid for 5 minutes or something. Describe your object without having to adjust of extend them... I wouldn't know why it could be better than extending though...

  • (cs) in reply to Eq

    heh..call it a 'Fully Flexible Enterprise Solution'

    ..one line of code..

    10 SHELL "QBASIC.EXE"

  • (cs) in reply to Mellon
    Anonymous:
    Could it be more usefull to add some more attributes to the class? such as an expiration time/date? Saying, the object is only valid for 5 minutes or something. Describe your object without having to adjust of extend them... I wouldn't know why it could be better than extending though...


    Most cache implementations do something like this. (Because extending cached objects is not an option when you write a generic module for caching.)

  • Onitake (unregistered) in reply to Derek
    Anonymous:
    Believe it or not, I've actually had to implement something like this before. In WebLogic, when you store something in the session, if the value you store implements Serializable, it insists on serializing it to store it, which wastes memory and CPU, and breaks the "==" comparison, and is unnecessary if you're not clustering the sessions. We created a stupid (non-Serializable) wrapper class basically exactly as above so that we could store a particular Serializable object in the session without those problems.


    you do know about transient, do you?
  • Daniel Serodio (unregistered) in reply to biziclop
    biziclop:
    Actually, OOP declares that abstractions should only be applied if they have some real world sense and never for sole technical purpose.

    Where the hell did you read that? There are tons of reasons for creating abstractions, and "having some real world sense" is the least important of them!!! Does "HashMap" have any "real world sense"? Do imaginary numbers have any "real world sense"? Geez!
  • qbolec (unregistered) in reply to Daniel Serodio

    Anonymous:
    biziclop:
    Actually, OOP declares that abstractions should only be applied if they have some real world sense and never for sole technical purpose.

    Where the hell did you read that? There are tons of reasons for creating abstractions, and "having some real world sense" is the least important of them!!! Does "HashMap" have any "real world sense"? Do imaginary numbers have any "real world sense"? Geez!

    HashMap sounds like map leading to hash.

    Imaginary numbers sound like somenthing used in tax forms.

    Captcha=java

  • Jeremy Lakeman (unregistered)

    "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem."

    David Wheeler

  • (cs) in reply to Daniel Serodio
    Does "HashMap" have any "real world sense"? Do imaginary numbers have any "real world sense"? Geez!


    HashMap implements something like a dictionary (its predecessor Hashtable even had an abstract superclass Dictionary). Imaginary numbers have very real applications, for example in representing electricial impedance (resistance to alternating current, which can have a capacitive and an inductive component).


    Useful abstractions always have some sort of real world sense. But I don't see how technical abstractions such as a cache would not be considered "real world".

  • (cs) in reply to Eq
    Anonymous:
    That's the same kind of thinking that would implement a BASIC interpreter in BASIC.


    Implementing a language's interpreter or compiler in itself is one of the, um, basic steps in designing a new language. Unless it's something like Malbolge, where nobody could do that.
  • shmoopy (unregistered) in reply to Brent
    1. if i want objects that have hashCode and equals to be considered as different, and that only the same reference will mean equality, then i'll wrap them in ObjectWrapper

      2. if a framework i use has an ISomeInterface interface, and in some places in the code it uses 'if (o instanceof ISomeInterface)', and i have an object that implements this interface, but i want to avoid this behavior, then i can wrap it in ObjectWrapper
  • Jed Wesley-Smith (unregistered) in reply to Jesse Wilson

    Or just use IdentityHashMap...

    0

  • Marcelo (unregistered)

        I am working on/inheriting a system with a few hundred classes and I have to deal with something worse.

    <font color="#0000ff">public class <font color="#000000">Object </font>: System.Object
    {
        <font color="#006400">// you dont even want to know whats between these brackets</font>
    }</font>

    And yes, all the hundred of classes in the project inherit from this conveniently named class.

  • (cs) in reply to Marcelo
    Anonymous:
        I am working on/inheriting a system with a few hundred classes and I have to deal with something worse.

    <font color="#0000ff">public class <font color="#000000">Object </font>: System.Object
    {
        <font color="#006400">// you dont even want to know whats between these brackets</font>
    }</font>

    And yes, all the hundred of classes in the project inherit from this conveniently named class.



    please god and for the love of all this is holy tell us what is inside the braces.  then tell us what on this green earth made someone name that class Object.  what is the common functionality of every class in your entire system that was defined in System.Object?
  • (cs) in reply to Brent

    Last time I checked, String (and all classes in Java) extends Object.
    Therefore you could perform the following...

    Object someString = "a string";
    ObjectWrapper ow = new ObjectWrapper(someString);

    if(someString instanceof String)
      System.out.println("This will run, because the someString reference was indeed assigned an instance of String.");

    if(ow instanceof String)
      System.out.println("Holy crap, this line won't run!!!");

    if(ow.getObject() instanceof String)
      System.out.println("Woah but this one will!");

    Just because we're passing a reference of type Object in the constructor doesn't mean that the object being referenced was instantiated as new Object(). Thus it is quite valid to wrap the data if you want to hide its instantiated type from an instanceof keyword, but still be able to get to it if you need to.
    Looks like a reasonable use to me.

  • (cs) in reply to tster

    tster:
    Anonymous:
        I am working on/inheriting a system with a few hundred classes and I have to deal with something worse.

    <FONT color=#0000ff>public class <FONT color=#000000>Object </FONT>: System.Object
    {
        <FONT color=#006400>// you dont even want to know whats between these brackets</FONT>
    }</FONT>

    And yes, all the hundred of classes in the project inherit from this conveniently named class.



    please god and for the love of all this is holy tell us what is inside the braces.  then tell us what on this green earth made someone name that class Object.  what is the common functionality of every class in your entire system that was defined in System.Object?



    <FONT face=Tahoma color=#000000>maybe they didn't want the object in the System namespace...
    "System.Object? it's not ours, but EnterpriseyCompanyNameHere.Object is and it sounds very good and very enterprisey indeed..."

    oh well...



    </FONT>

  • Dave (unregistered) in reply to Mellon

    <font size="3">It's called composition and it happens all the time. Except usually you provide a way to access methods of the "composited" class.
    </font>

  • asdfasdfsad (unregistered) in reply to Dave

    When is Oreilly coming out with "ObjectWrapper Distilled"?  I need to improve my OO skills and that sounds like the perfect book for me!

  • Chicken (unregistered) in reply to missing

    Anonymous:
    What Im mostly afraid of is, that so many people have mentioned ideas of possible legal use of this within Java... I can hardly remember any other wtf with similar characteristics...

    "Legal" uses are probably due to WTFs in other pieces of software :P

     

  • Cow (unregistered) in reply to Chicken
    Anonymous:

    "Legal" uses are probably due to WTFs in other pieces of software :P

    It's a WTF Wrapper!

  • csrster (unregistered) in reply to Derek
    Anonymous:
    Believe it or not, I've actually had to implement something like this before. In WebLogic, when you store something in the session, if the value you store implements Serializable, it insists on serializing it to store it, which wastes memory and CPU, and breaks the "==" comparison, and is unnecessary if you're not clustering the sessions. We created a stupid (non-Serializable) wrapper class basically exactly as above so that we could store a particular Serializable object in the session without those problems.


    In Java 1.6 you'll be able to do this with

    public class MyClass extends SomeOtherClass does not implement Serializable {}
  • (cs) in reply to Simon
    Anonymous:
    I Object!


    Wrap the object enough times and it will gain the complexity for autonomous thought. Then:

    "I, Object!"

Leave a comment on “Rewrapping a Wrapper Wrapper”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article