Comment On Not Non-uninvisible, addfunk(), and More

#define HEX(frist) 0xfrist // "SIMPLIFY FIRST POST"

joe.edwards:

#define HEX(frist) 0x ## frist // "SIMPLIFY FIRST POST"

FTFY!

It's simple enough to understand: each time you invoke the visibility toggle, add another negation to the comment in the source code. Easy!

/*
* Copyright (c) 1995, 2008, Oracle and/or its affiliates. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* - Neither the name of Oracle or the names of its
* contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
* IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
* PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
* NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
* SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/

/**
* The UselessComment class implements an application that
* simply print a useless comment.
*/
class UselessComment {
public static void main(String[] args) {
System.out.println("Not-Frist"); // Display the string.
}
}

Clearly, $two = -funk; what's the problem?

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

The MutableBoolean should be obvious for anyone familiar with the java wrapper classes. java.lang.Boolean is not Mutable so MutableBoolean is a good name for boolean wrapper with a public non final value field

It should be illegal and be subject to third party claims to claim copyright on public domain works.

the IsNotOkay parameter isn't as redundant as you might think. If the final destination of these properties is to be bound to a view (in XAML), it's much simpler to have two properties like this than to have to write a converter to invert the value.

TRWTF is that he should have written assignment operater overide methods for MutableBoolean.

It's appalling that Oracle provides "Hello World" as-in and without any warranty whatsoever. Shame on them! ;-)

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

I think I might kinda have maybe reverse engineered Oracle's code into a different language without even knowing it.

Have I broken some copyright law there?

The code is worse than the comments today. That doesn't happen very often.

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

Except be able to bypass Java's pass-by-value mechanism. Or use the boolean inside an anonymous inner class; the variable needs to be final for that, but you can't make the primitive boolean final or you can't change it. So you use a MutableBoolean wrapper, where the wrapper variable can be final but its value can still change.

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

TRWTF is Java...
http://commons.apache.org/lang/api-2.5/org/apache/commons/lang/mutable/MutableBoolean.html
http://download.oracle.com/javase/6/docs/api/java/util/concurrent/atomic/AtomicBoolean.html
http://stackoverflow.com/questions/3786825/java-volatile-boolean-vs-atomicboolean
http://stackoverflow.com/questions/1385481/mutable-boolean-field-in-java

And fucking of course the red-headed step child nobody loves or wants, akismet...

Ginormous Coward:

It should be illegal and be subject to third party claims to claim copyright on public domain works.

You would be interested in this site: techdirt.com.

"While taking a stroll through the code on a new project, I came across a fantabulous override of ToString," Jay writes, "I guess you never know when this will be null."

It turns out it is possible, though not in C# but still...

http://stackoverflow.com/questions/3143498/why-check-this-null

So my guess is author of "this == null" may be former MS employee...

Or more generally (for objects):

public class MutableWhatever<T> {

   public T value;

   public MutableWhatever(T value) {

      this.value = value;

   }

}

If you are really lazy you can use an array of size 1 instead. This is necessary due to Java's lack of pass by reference, as every primitive is pass by value, and every object is pass by value of reference.

Riory:

"While taking a stroll through the code on a new project, I came across a fantabulous override of ToString," Jay writes, "I guess you never know when this will be null."

It turns out it is possible, though not in C# but still...

http://stackoverflow.com/questions/3143498/why-check-this-null

So my guess is author of "this == null" may be former MS employee...

Have you ever heard of Hanlon's razor?

1) Write "Hello World" Program
2) Copyright program
3) ????
4) Profit!!

Yep. That's Oracle.

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

Not that I am agreeing with this style or anything, but:

MutableBoolean a = new MutableBoolean(false);

MutableBoolean b = a;

a.value = true;

System.out.println(b.value);

I've heard of Heinlein's Razor :)

Riory:

I've heard of Heinlein's Razor :)

Pedant... ;P

C-Octothorpe:

Riory:

I've heard of Heinlein's Razor :)

Pedant... ;P

They're the same thing. "Hanlon's Razor" is argued by some to be a corruption of the name "Heinlein's Razor".

But of course you know all this because you googled it.

Maybe the function:

public function addfunk($one, $two) {
$val = $one - $two;
return $val;
}

is wrapped in a validation that requires parameter $one to be positive and $two to be negative? Which would still make it addition via double negatives? Probably a long shot but has a tiny chance of still being valid :)

@Deprecated:

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

Not that I am agreeing with this style or anything, but:

MutableBoolean a = new MutableBoolean(false);

MutableBoolean b = a;

a.value = true;

System.out.println(b.value);

It would also be useful if you want more than one class instance to share the same boolean (or any other primitive). It's not uncommon to do that in C++ where you would be able to store a pointer to a primitive in your class, and check it to see if someone, somewhere changed it. It could have been changed by any class and would not have gone through any of your object's code.
You don't have pointers in (safe) C# and java, hence the "MutableBoolean" class which basically acts as a pointer. The only WTF here is that this is basically intentionally bypassing the safety features of your compiler.

This is like boolean math.

Let's see:

= "not non-uninvisible"

= "not" * "non-" * "un" * "in" * visible

= false * false * false * false * visible

Note 1: false * false = true

= true * true * visible

Note 2: true * true = true

= true * visible

= visible

It makes the dialog visible.

"I know what a Boolean is, and a know what Mutable means," Casey Borders writes, "yet I have no idea what a MutableBoolean is."

With all due respect Casey, the WTF in this instance isn't really with that code...

Anonymath:

It makes the dialog visible.

What it should do is make the black eye inflicted on the original writer visible.

Erzengel:

@Deprecated:

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

Not that I am agreeing with this style or anything, but:

MutableBoolean a = new MutableBoolean(false);

MutableBoolean b = a;

a.value = true;

System.out.println(b.value);

It would also be useful if you want more than one class instance to share the same boolean (or any other primitive). It's not uncommon to do that in C++ where you would be able to store a pointer to a primitive in your class, and check it to see if someone, somewhere changed it. It could have been changed by any class and would not have gone through any of your object's code.
You don't have pointers in (safe) C# and java, hence the "MutableBoolean" class which basically acts as a pointer. The only WTF here is that this is basically intentionally bypassing the safety features of your compiler.

I still don't get the point. If you have multiple classes sharing the same boolean, surely that boolean is significant enough that it has a property name in a class that is much more meaningful than MutableBoolean.

should work for all types except for typeof(Wife), which is never Mutable :)

I think MutableBoolean is useful and have had to use it at some point. Code snipper:

[code]
final MutableBoolean a = new MutableBoolean(false);

Callback<xxx> callback = new Callback<xxx>() {
public void onSuccess(xxx val) {
if(a.value) {
// do something
} else {
// do something else
a.value = true;
}
}
};

// Make two async calls that end up eventually calling callback.onSuccess. Note that this was written in GWT, so no concurrency issues.

Steve The Sexless:

Pyschonypath:

It makes the dialog visible.

What it should do is make the anus of the original writer swollen and bleeding.

This comment is not non-uninteligible.

josefx:

The MutableBoolean should be obvious for anyone familiar with the java wrapper classes. java.lang.Boolean is not Mutable so MutableBoolean is a good name for boolean wrapper with a public non final value field

Even though I've never used Java I immediately understood what was going on. It's not a WTF unless it's duplicating library functionality.

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

This allows pass-by-reference instead of pass-by-value.

hoodaticus:

I still don't get the point. If you have multiple classes sharing the same boolean, surely that boolean is significant enough that it has a property name in a class that is much more meaningful than MutableBoolean.

Sharing it with a delegate, perhaps?

private boolean isLoggingEnabled() {
return MAX_NUMBER_ATTACHMENTS != -1;
}


I may need to get this on a t-shirt...

Public Function IsObjNothing(ByRef poObject As Object) As Boolean

    '***** 04/21/2004 - corrected function IsObjNothing expression type

    'IsObjNothing = (TypeName(poObject) = Nothing)

    IsObjNothing = (TypeName(poObject).ToUpper = "NOTHING") End Function

Can't you just look at the object to see if it's nothing? I mean, that's all the function is doing. The fact that the original developer thought to add this function to the codebase to begin with makes the WTF (is nothing case-sensitive?) less of a surprise.

Funny use for the word "corrected" though. :)

Wonk:

1) Write "Hello World" Program
2) Copyright program
3) ????
4) Profit!!

Yep. That's Oracle.

1) Write "Hello World" program
2) Copyright program
3) Have some random site (TDWTF) distribute your program verbatim
4) Sue the hell out of random site. That'll teach them to obey copyrights
5) Profit!!! (For the lawyers)

QJo:

C-Octothorpe:

Riory:

I've heard of Heinlein's Razor :)

Pedant... ;P

They're the same thing. "Hanlon's Razor" is argued by some to be a corruption of the name "Heinlein's Razor".

But of course you know all this because you googled it.

So, naturally, there had to be two popular writers who said roughly the same thing who also happened to have similar names.

captcha: eros. Time Enough for Eros?

Always the same fuss over "this" being null. Keep in mind that "this" is merely syntactic sugar for another parameter implicitly passed to a function.

In C one might write

void class_A__method(object* this,int a,int b,int c)
{
class_A__othermethod(this,a,b,c);
class_A__thirdmethod(a,b,c);
}

whereas in C++ you might write

class A
{
void method(a,b,c);
void othermethod(a,b,c);
static void thirdmethod(a,b,c);
}

void A::method(a,b,c)
{
this->othermethod(a,b,c);
thirdmethod(a,b,c);
}

It's all the same. Just because "this" is passed implicitly (and sometimes unnecessarily!) in object oriented programming, that doesn't mean it's always defined!

Normally in a class you'd define functions that don't require the object pointer as static methods. However, in some cases it's useful that a method can be called both with or without object pointer.

A bit exotic, no doubt. But there *are* perfectly legitimate uses for "this" being null.

Mutable variables are what are used when mime-encoding algorithms.

Then you put the code into an non-uninvisible box.

Then you dump the programmer into the scorpion pit.

--Joe

ipodsis:

Steve The Sexless:

Pyschonypath:

It makes the dialog visible.

What it should do is make the anus of the original writer swollen and bleeding.

Still not worse than the code, but nice try.

PedanticCurmudgeon:

The code is worse than the comments today. That doesn't happen very often.

Now that zunesis has showed up for work, I may have to retract this comment.

Loren Pechtel:

josefx:

The MutableBoolean should be obvious for anyone familiar with the java wrapper classes. java.lang.Boolean is not Mutable so MutableBoolean is a good name for boolean wrapper with a public non final value field

Even though I've never used Java I immediately understood what was going on. It's not a WTF unless it's duplicating library functionality.

hoodaticus:

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

This does nothing that a simple local variable wouldn't do.

This allows pass-by-reference instead of pass-by-value.

hoodaticus:

I still don't get the point. If you have multiple classes sharing the same boolean, surely that boolean is significant enough that it has a property name in a class that is much more meaningful than MutableBoolean.

Sharing it with a delegate, perhaps?

So this is to essentially get around a limitation of java where everything is passed by value, including objects? Man, I am *so* glad I haven't touched java in years...

ac:

Isn't the MutableBoolean just a way to make the boolean (value) type into a reference type ("box" it, in .NET terms)? Because values types are passed by uh... value, you can't change the original value, so it appears "constant".

Not that this is already covered by the java.lang.Boolean class or anything...

Invalid point.
As MutableBoolean uses keyword "boolean" instead of "bool" we already know it can't be C#, probably it's Java code already.

The best usecase of using a MutableBoolean is when a method needs to return more than one value. E.g.

public CoolFactor calculateCoolness(Stuff stuff, Stuff moreStuff, MutableBoolean resultIsAswome)

Riory:

So my guess is author of "this == null" may be former MS employee...

Nothing to do with MS. In C++, you can call a member function on a NULL pointer (or any other invalid pointer) - and you won't even run into problems if that function never accesses any member variable. Checks like (this != NULL) are pretty common in C++.

Artemus Harper:

The best usecase of using a MutableBoolean is when a method needs to return more than one value. E.g.

public CoolFactor calculateCoolness(Stuff stuff, Stuff moreStuff, MutableBoolean resultIsAswome)

At least in .Net, you have the option of passing a value by ref* (though this can give you some very strange behaviors), and objects are always passed by ref. Heck you can even pass an objects reference by ref so you can do reference swapping successfully, not that there are too many situations where you would, but...

* - I remember writing my own struct with some properties, passing an instance of that by ref to a method, changing some properties in the method, and none of the changes sticking with the original instance after the method call returns. Could be fixed now though (I tried this I think back in 1.x or 2.0 days).

That Oracle header is a BSD license.

http://www.opensource.org/licenses/BSD-3-Clause

Yes, something like MutableBoolean allows you to bypass Java's pass-by-value paradigm, which arguably could be a tacit admission of a defect in Java. But it could also be used to "promote" a primitive to an Object, thus allowing it to be used in contexts where otherwise it would not be allowed. I think there's good reason for a primitive vs object distinction, but yes, it does create this extra complexity at times.

Here's a rather obvious example of where a MutableBoolean would be useful:

HashMap<String,MutableBoolean> products=new HashMap<String,MutableBoolean>();
public void setActiveFlag(String product)
{
MutableBoolean active=products.get(product);
if (active==null)
{
active=new MutableBoolean(true);
products.put(product,active);
}
active.value=... some logic that decides if it's active ...
}

Yes, you could use a Boolean instead and create a new Boolean every time the value changes. But that's a lot of extra object creation and destruction, and it takes a few more lines of code to do. So this solution means fewer lines of code (equals easier to maintain) plus faster run time. Win/win.

I routinely create MutableIntegers for just this purpose. Then I can write

MutableInteger n=collection.get(key);
n.value+=1;

instead of

Integer n=collection.get(key);
int value=n.intValue()+1;
Integer newN=new Integer(value);
collection.put(key, newN);

The first method can be read and understood in an instant. The second requires at least a few extra seconds of thought, and someone reading it quickly is more easily confused. (And yes, we could cram it all into one line of code and eliminate the temporary variables, like:

Integer n=collection.get(key);
collection.put(key, new Integer(n.intValue()+1));

I guess it's debatable if that is better or worse.)

Okay, a couple of seconds isn't a lot. But when you have programs filled with unnecessary complexities, each of which takes an extra couple of seconds of your time to figure out, it adds up.

captcha: sino. I tried sqrt(1-cos2o), but for some reason it didn't accept that.