Comment On A Wrapper Wrapper

So...ummm... how could this be used?
For occasions when coding standards dictate that you can't pass around 'object'?

Keep 'em coming - it's great education for people who just don't realise just how much dumb programming goes on out there.

Geez, you kind of hope that this code is incomplete. That once the rest of the ObjectWrapper class has been implemented we will all be shocked and awed at the architectual brillance of this software developer. In fact so taken back by the innovative use of the Decorator pattern that the Gang of Four will celebrate the climatical usage of this pattern. That for years afterwards, bloggers around the world will speak of the moment ObjectWrapper was discovered and changed the way we code software.

While I'm not sure this code looks very useful, I can name a case when code like this has been useful for me. Perl's common object-relational mapping framework, Class::DBI, has a very simple method for mapping database columns to objects. You tell it the class and inflation method, it calls the method on the class using the column value, and you get the object. If the returned value isn't a member of that class, things die. There are other ways do deal with the problem, but one is to create a plain brown wrapper for all objects that might be returned from a polymorphous column. Class::DBI is happy because the object isa the right class, and the programmer can easily use the object as its real type indicates (via proxying of methods). This programmer's code requires that the getObject method serve as the proxy, but it doesn't strike me as incredibly awful and pointless out of hand.

in .net if you wanted to have an interface to a class that had a retarded public variable named Object you'd have to wrap it in a property like to access it via interface.

Me thinks that this developer had a special keyboard with a button that, if pressed, would send the characters 'o', 'b', 'j', 'e', 'c', 't' in one fell swoop.

First, I have to say that the code appears to be highlighted in a c# editor while the code itself seems to be java.

Second, the class could very well be a base class for derived wrappers like this one:

public class StringWrapper extends ObjectWrapper
{
public StringWrapper(String string)
{
super(string);
}

public String getString()
{
return getObject().toString();
}
}

See now? The usefulness of ObjectWrapper should be obvious by now. ;)

It is JAva (how did i forget to mention that)? ... and you are correct, it was hilighted using the Squishyware VB.NET/C#/XML syntax hilighter ... which probably explains why it didn't hilite so well. But, I don't have any other hiliters ... so if you have a URL for a Java->HTML and SQL->HTML, that would be fantastic!

Very useful, who knows when the definition of Object will change....

If it had a setObject, then I'd assume it was for getting a pseudo-byref parameter in Java.

If this were C#, I'd assume he heard someone say that manually wrapping ValueTypes in an object can improve performance in certain scenarios, and he just assumed that wrapping an Object would get the same benefits.

He doesn't per chance use this code to create an ObjectWrapper around an ObjectWrapper, does he?

I think this is a Why The F*, not a What.

i think it's part of some elaborate "object laundering" scheme, where he is trying to hide the true objects he is using. :)

Welcome to the Department of Redundancy Department.

Well, maybe this is to prevent that annoying System.InvalidCastException, since you are guaranteed that the object will always be of type ObjectWrapper :).

what's next?

public class ObjectWrapperFactory {
public static ObjectWrapper wrapup(int depth, Object obj) {
if (depth < 0) {throw new IllegalArgumentException("send me a non-negative number, not: "+depth);}
if (depth == 0) {
return obj;
}
return wrapup(depth-1, new ObjectWrapper(obj));
}

}

This looks a lot like a <a href="http://java.sun.com/j2se/1.3/docs/api/java/lang/ThreadLocal.html">ThreadLocal</a> but just completely useless instead.

ThreadLocals are way cool though. I used them to make a 3 line fix to a broken persistence framework we had developed which was crapping its pants under concurrent load in production. Made a very angry customer very happy very quickly...

looks like a singleton without singleton

Sometimes you don't want the original object's hashcode and equals methods to get called by the collection classes. This is a way to achieve that.

I think you need to actually know Java before you criticise it. Stick to the VB and SQL crapula.

This class has become somewhat of a cult phenomena around the office. It has even inspired creativity in out developers as in the image linked below :)

http://weblog.bbzzdd.com/media/objectwrapper.jpg

I'm guessing it was a jr. from some other lang who want an out param where they could change the object instance that was passed back. coures
new Object[1] would do the trick.

BTW Chris that image is classic.

- Peace
Dave

I could think of possible (obscure) reasons it might make sense to do this but without any context we'll never know if this code is smart or dumb.

That code is real. I can vouch for it; I've seen it in the repository.

As Dave said, it's true that with that class you will get a different hashcode than the one from the wrapped object. And yes, I guess sometimes that could be useful with some kind of java (and c#) collections. So yes, basically without knowing the spec we could be b*tching about a perfectly valid code.
BTW, I don't agree with Dave aboutthis site sticking with VB & SQL only code snips, after all it's fun looking at some wild code out there as it's fun looking at some hasty review that ends proven wrong (like the one I made), and in the end we can learn a little, so please keep the snips coming (java ones included).
... The O'Reilly cover was fantastic!.

"Sometimes you don't want the original object's hashcode and equals methods to get called by the collection classes."

When?

And is this a "good" way to achieve that? It seems hopelessly obscure to me. Maybe it is a technical workaround, but that doesn't make it less of a hack (or lessy funny, just for the sheer obfuscation of it).

"Sometimes you don't want the original object's hashcode and equals methods to get called by the collection classes."

Agreed. That why Java lets you OVERRIDE methods. This code could never be helpful.

@Brad
But what if you don't want (or can't) override the hashcode (and equals) method of the collection items?
As I see it now, ObjectWrapper could be an easy hack to get a different hash. Maybe isnt the best way of doing it but it works.

Personally I have a problem with this part.

private Object object;

If C type code isn't confusing enough WTF do people need to declare variables the same name (different case) as the class?

I've seen whole applications done up like this, it's nasty and makes comming behind the person a real pain in the butt.

I personally know too many people that have no problem with this, it's scary.

Joe

Even if we give the programmer (Dave, maybe?) the benefit of the doubt and assume that this is actually useful, I have to call WTF on anyone who checks in something like this WITHOUT ANY COMMENTS.

@Brad (who does not know what he's talking about)

Because sometimes you want to distinguish between the REFERENCE and the OBJECT, and collections only do the former if the Object's hashcode and equals methods are used. You could derive a new class from the original in order to do this, but then it would:

(a) be less universally useful
and
(b)probably require greater overhead than the original example

@Breddy (who does)

No, I didn't write this, but I have done the equivalent of this for perfectly good reasons. I agree that not commenting is a capital offence, but hardly amusing in itself.

Personally I think that any WTF submitted with correct comments doesn't qualify, however hapless the implementation, since it is at least fixable.

Submitting apparently good code to thedailywtf without sufficient context to mark it a bug is itself pretty hapless.

I don't comment on VB and NET wtfs because I don't use them enough to know I'm not talking bollocks. I commend the same approach to the rest of you.

The author of the code in question, having just read the GoF Design Patterns book, was eager to go out and create a pattern. ObjectWrapper is the product of his zeal. Nothing more.

Keep in mind that this is the same guy who wanted to subclass String and created an intermediary class called "JObject" that sits between java.lang.Object and the rest of the classes in his "framework."

@Chris

"Keep in mind" == "Hear for the first time".

Sure, the guy may be a super-duper numero uno doofus. But without the context of the bug, how were we supposed to know that ?

I've heard far too many colleagues ridicule code that they thought they understood. Sometimes I have to stop them from "fixing" things that were that way for a very good reason.

At least your clown is reading the right books! Give him a copy of "The Mythical Man Month" and a few other "best practices" texts to keep him out of mischief.

Totally correct!
Fix Java´s lack of by ref arguments.
VB coders should understand that, for some people 'A' differs from 'a'.

You're either trolling or a complete incompetent.

@Dave (who should take a data structures class before commenting again)

Could you please give me any concrete example of where that would be useful? Why would you want different implementaions of equals and hashcode be needed for the same object ever?

(Before you answer bear in mind you can make a custom comparator or custom collections class. )

I don't see what the big deal is -- this is a way to get double
indirection in a language that doesn't support pointers. The object
wrapper is as close as you can get to a pointer-to-pointer-to-void in
Java. It doesn't come up often, but there are a very small number of
cases where this is really handy.

So two claims have been made about the possible reasons for this code.
One is the "passing a reference to a reference" argument, which seems
valid enough, could have been replaced by an Object[1], but this
solution provides more type safety and (with some commenting) could
make the intention more clear than it would be if an array were used.



The second argument is about allowing a different sense of
hashing/equality. While this seems more likely than the first, it is
still worth pointing out a few things. The type of hashing/equality the
wrapper provides is identity (ie: only the same instances have the same
hashcodes and are equal). The place that hashing/equality is most often
used is in HashMap - but if you wanted identity hashing/equality for
use in a Map, why wouldn't you use the aptly named IdentityHashMap?
Perhaps if you didn't have access to the offending HashMap, and just
had to provide objects for it.. this whole line of reasoning seems a
bit obscure and I think the first line (ref to ref) is far more likely
and not too unusual - some commenting/documentation wouldn't go astray
of course.

This might be too geeky, but try vim.  http://www.vim.org/ or cream (http://cream.sf.net).



Paste in the code, then (for Vim):

    Syntax->Show Filetypes in Menu

    Syntax->...select filetype from menus...

    Syntax->Convert To HTML



Copy/Paste.  It's got highlighting for almost every language known
to man and it's a damned fine editor too once you get used to it.



--Robert

:

Personally I have a problem with this part.



private Object object;

While I try my best to avoid this, if I find myself looking for a
thesaurus so I can get a different name (ie private Object
somethingHavingMaterialExistance;), I tend to just stick with a
different case. This is, of course, when the class's name is sufficient
in explaining the purpose of the object. At that point, if you still
hate just a case change, I've seen a lot of this (and it bothers me).

[code language="c#"]private OgreWrapper myOgreWrapper;[/code]

or at my work...

[code language="java"]private StarRate theStarRate;[/code]

But if like you said, the whole application was done using just a case difference, I'd raise a WTF as well.

Even as a way of indirection (reference to a reference) the provided
class is useless (Object[1] would work). What good does an indirection
do you if you can't change it? After all, the ObjectWrapper is missing
a setter...

There's nothing really weird about this in terms of it's style.  Hungarian notation and the such is vey much looked down upon in the Java world.  If it's just an Object and has no other meaninful name, call it Object.  I can't think of a better name for it.

This code is pretty much WTF because there's no point in doing this as you cannot modify the object reference.

But sometimes this kind of thing is neccesary because there is no pass by reference mechanism in Java.

 

Anonymous:

@Brad
But what if you don't want (or can't) override the hashcode (and equals) method of the collection items?
As I see it now, ObjectWrapper could be an easy hack to get a different hash. Maybe isnt the best way of doing it but it works.

You could use a different Collection that doesn't use the hashCode or equals such as a TreeMap and define a custom Comparator.

Anonymous:

I don't see what the big deal is -- this is a way to get double indirection in a language that doesn't support pointers. The object wrapper is as close as you can get to a pointer-to-pointer-to-void in Java. It doesn't come up often, but there are a very small number of cases where this is really handy.

I can't think of any (good ones) where you wouldn't be need to be ablet to modify the wrapped reference.

Hi guys.  I did find this funny.  I even set my wallpaper to
the "ObjectWrapper distilled".  However, I just came upon an
occassion where I actually wrote code like this.



I am writing a URLStreamHandlerFactory that should delegate to a nested
implemenation which which it was initialized.  Instead of writing
this boilerplate code in my actual concrete implementation I wrote a
base class FacadeURLStreamHandlerFactory (laugh at the name if you
must).  I was suddenly astonished that the only difference from
ObjectWrapper was essentially the field type (instead of Object it's
URLStreamHandlerFactory of course).



Now the *purpose* is for a subclass to override the accessor to do some
sort of interception (and perhaps conditionally delegate to the
superclass nested implementation).  So I can see how this code
might actually be used.  The question then is simply whether the
author should have made this class abstract because it doesn't have any
utility by itself.

Anonymous:

Now the *purpose* is for a subclass to override the accessor to do some sort of interception (and perhaps conditionally delegate to the superclass nested implementation).

Do you have reason to believe that this will actually be done?  One of the great things about OO and design patterns is that you can create new implementations in the future.  I don't understand why you would need to write this before it's needed.

Joe:

Personally I have a problem with this part.



private Object object;



If C type code isn't confusing enough WTF do people need to declare variables the same name (different case) as the class?

What better name for an Object could there be than "object"?

>If C type code isn't confusing enough WTF do people need to declare variables the same name (different case) as the class?

In java it is common to use a variable, named by taking the upper case letters of its class or interface name and writning them in lower case, for the object name in a for each loop ir a similar structure.

Jacob & Co. Watches
http://replica038.com/Jacob-Co-Watches.html