Comment On Rewrapping a Wrapper Wrapper

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

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!

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

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.

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.

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

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.

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.

Alex Papadimoulis:

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 Object object;
   public ObjectWrapper(Object object)
   {
      this.object = object;
   }
   public Object getObject()
   {
      return object;
   }
}

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

>BiggBru

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 :)

Brain!  Brain!  What is Brain!

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 

{

   private  object;

   public ObjectWrapper( object)

   {

       this.object = object;   

   }   

   public Object getObject()   

   {

       return (Object)object;

   }

   public  getT()   

   {

       return object;

   }

}

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".

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.

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.

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];

}

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

Assuming this is java you could much better use Templates to avoid neccessary Casts to the original Object Type.

public class ObjectWrapper<T extends Object>
{
   private T object;
   public ObjectWrapper(T object)
   {
      this.object = object;
   }
   public T getObject()
   {
      return object;
   }
}

By doing it this way you can easyly wrap anything up like:

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

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.

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...

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

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.

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

Anonymous:

Assuming this is java you could much better use Templates to avoid neccessary Casts to the original Object Type.

public class ObjectWrapper<T extends Object>
{
   private T object;
   public ObjectWrapper(T object)
   {
      this.object = object;
   }
   public T getObject()
   {
      return object;
   }
}

By doing it this way you can easyly wrap anything up like:

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 o1 = new ObjectWrapper(new Integer(15));

ObjectWrapper o2 = new ObjectWrapper(new String("15"));

ObjectWrapper o3 = new ObjectWrapper(new Double(15.0));





// we create an array to store them all

// we cast them all to the same class



new Vector wtf = new Vector;

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 :)

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.)

I Object!

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

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.

Anonymous:

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

public class PlasticObjectWrapper extends ObjectWrapper
{
}

Captcha = enterprisey

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...

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

..one line of code..

10 SHELL "QBASIC.EXE"

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.)

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?

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!

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

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

David Wheeler

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".

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.

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

Or just use IdentityHashMap...

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

public class Object : System.Object
{
    // you dont even want to know whats between these brackets
}

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

Anonymous:

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

public class Object : System.Object
{
    // you dont even want to know whats between these brackets
}

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?

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.

tster:

Anonymous:

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

public class Object : System.Object
{
    // you dont even want to know whats between these brackets
}

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?

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...

It's called composition and it happens all the time. Except usually you provide a way to access methods of the "composited" class.

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

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

 

Anonymous:

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

It's a WTF Wrapper!

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 {}

Anonymous:

I Object!

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



"I, Object!"