31. Water shapes its course according to the nature
of the ground over which it flows; the soldier works
out his victory in relation to the foe whom he is facing.

32. Therefore, just as water retains no constant shape,
so in warfare there are no constant conditions.

But then again, we all know war is agile, right?

Or another quote I heard (source unknown, original language Swedish):

Meeting all requirements in programming is like walking on water.  It’s easy if the water and the requirements are frozen…

I’m just fresh from having tried to iterate a list… and delete items from it while iterating.  In .NET with C#.

It turns out a statement like:

void deleteFromList(IList<X> list) {
     foreach (X x in list) {
        if (x.DeleteMe) {
            list.Remove(x);
        }
    }
}

Will throw an InvalidOperationException stating you cannot perform a foreach and delete at the same time.  This is actually not that big of a surprise, or it shouldn’t be…  the same happens in Java if you delete and iterate at the same time.

This is how I would have done this in Java:

void deleteFromList(List<X> list) {
     Iterator<X> itr = list.iterator();
     while (itr.hasNext()) {
	X x = itr.next();
        if (x.DeleteMe) {
            itr.remove();
        }
    }
}

It’s simple, clean and it does not throw exceptions. If you believe the code may be run asynchronously, slap on a “synchronized” and you’re home safe.

So, how to do this with .NET?  Well, you can’t use Enumerators (which are the .NET “equivalent” of iterators), they don’t have a remove method.  Further worse, if you are unlucky enough to run version 1.1 your only option seems to be some unholy concoction like:

void deleteFromList(IList<X> list) {
    IList<X> toBeDeleted = new List<X>();

    foreach (X x in list) {
        if (x.DeleteMe) {
            toBeDeleted.Add(x);
        }
    }

    foreach (X x in toBeDeleted) {
        list.Remove(x);
    }
}

Don’t even start a conversation on synchronization with this mixup.  Anyway, those who are “lucky” enough to code .NET 2.0 can do something like:

myList.RemoveAll(delegate(X x) { return x.DeleteMe; });

Now, if you’d like to base the “DeleteMe” calculation on some external paramter like input to the deleteFromList method or if you’d like to do more than just delete x you’ll have to experiment, it’s probably possible… with a solution like the double lists above perhaps?

Regardless.  Someone said it was old news to be a Java programmer, I can only guess because of the lower hour wastage when you program Java systems, which in turn means lower bills to the clients and finally lower wages to the programmers.

It costs to be on top…

exportDocumentView(java.lang.String absPath, java.io.OutputStream out,
boolean skipBinary, boolean noRecurse)

And in such prominent frameworks as Java Content Repository as well.

What’s my problem then? Double negations. In order to do exportDocumentView and get binary data and recursive export you’ll need to do:

exportDocumentView(“/path/to/my/Node/”, System.out, false, false)

Sure I can handle it… but… false to opt something in? I find it rather fishy. Call me an idiot but my brain just don’t deal with that kind of stuff easily…

What I would have wanted instead was:

exportDocumentView(java.lang.String absPath, java.io.OutputStream out,
boolean includeBinary, boolean recursive)

Which would have been called like:

exportDocumentView(“/path/to/my/Node/”, System.out, true, true)

For when we want binary data and recursive export, and like this for the case when we don’t want either or both:

exportDocumentView(“/path/to/my/Node/”, System.out, false, true)
exportDocumentView(“/path/to/my/Node/”, System.out, true, false)
exportDocumentView(“/path/to/my/Node/”, System.out, false, false)

I’m just saying. In my world false means “no” and “no” means don’t give me something or don’t do something:

“Don’t return binary data.”
“Don’t recurse the tree of nodes.”

To be compared with:

“Don’t skip binary data.”
“Don’t do no recursing.”

(But you’re free to curse? )