• Vlad Patryshev (unregistered) in reply to gus

    This is another good reason; and thanks for the hint, by the way!

  • Anon (unregistered) in reply to therealwtf
    therealwtf:
    TRWTF is not knowing the difference between Java and Javascript.
    TRWTF is not knowing the difference between Java and (what I assume to be) .NET.

    (hint: "Object" is Java, "object" isn't)

  • (cs) in reply to SR
    SR:
    PS DocumentDotWrite has to be an adbuster-buster
    Only if your ad-blocking program is retarded enough to look for Document.Write instead of simply blocking *.admnt.*
  • Jon (unregistered) in reply to Pffft!
    Pffft!:
    Jon:
    These two posts have me hurting.

    How would creating an array on the stack cause problems at all? If it's fixed size, who cares?

    Actual "objects" and primitives created with the "new" keyword are stored on the heap (Java and C#). The variables that reference those objects are stored on the stack.

    Even in C/C++ fixed-size arrays are created on the stack, so I'm not sure what QuestionMark is talking about.(http://www.chips.navy.mil/archives/99_apr/c++arrays.htm).

    The problems come when you (try to) use it later. What happens when a function returns an array on the stack?

    Wouldn't an array created on the stack inside of a function fall out of scope when the function's stack frame is popped (at the time of its return)? Or is that the point you were making?

    I'm not being rude, just ignorant. :)

  • anon (unregistered)

    The real WTF is that the Java guy uses arrays when the Collections framework is clearly much superior

    Captcha: oppeto

  • Coderess (unregistered) in reply to Steenbergh

    Duh! I hope you guys are being sarcastic with this solution.... You do realize that it would require the developer to KNOW array syntax in order to create the parameter array which defeats the whole purpose

  • meh (unregistered) in reply to QuestionMark
    QuestionMark:
    Maybe I'm off base a little bit, but in the languages I'm used to (C/C++), this would create an array on the stack, which would cause all sorts of hell if you used it later.

    Unless I'm mistaken, the new operator allocates memory on the heap. I was under the impression that this was the whole point of the new operator in c++?

  • (cs) in reply to apaq11
    apaq11:
    <joke> The real wtf is that he has to have a function for every number of parameters he wants to put into the array. He should just have one function that takes a parameter array. </joke>
    <dopeslap/>
  • AA (unregistered) in reply to Coderess
    Coderess:
    Duh! I hope you guys are being sarcastic with this solution.... You do realize that it would require the developer to KNOW array syntax in order to create the parameter array which defeats the whole purpose

    I hope you're being sarcastic, because otherwise it would mean you don't know what the "params" keyword means.

  • (cs) in reply to gus
    gus:
    There's nothing wrong with that function, IF you want to bottleneck all the document.write() calls, for like, say, debugging or logging.

    I can also imagine it exists for compatibility with ancient browsers that are no longer in use. Atlas has been around for quite awhile-- given the right userAgent, that might serve up a workaround for document.write not being present.

  • (cs) in reply to blakeyrat

    I can understand how arrays and square brackets are hard when you are half baked and running on empty from the monster gaming session the night before. Best to get these things peered reviewed before sending it out live. Unless of course the peer reviewers were the ones you were gaming with all night.

  • Pffft! (unregistered) in reply to Jon
    Jon:
    Pffft!:
    The problems come when you (try to) use it later. What happens when a function returns an array on the stack?

    Wouldn't an array created on the stack inside of a function fall out of scope when the function's stack frame is popped (at the time of its return)? Or is that the point you were making?

    I'm not being rude, just ignorant. :)

    That is exactly the point, also what QuestionMark meant by "all sorts of hell". Of course, since the arrays are created by "new", they're created on the heap, not on the stack also in C++, so QM was indeed "off base a little bit".

  • Ari (unregistered) in reply to Anonymous

    This is correct. I can confirm because we built the same thing at DoubleClick. My guess is that Atlas stole it from us.

  • (cs)

    These code samples remind me of some incredibly brilliant code I saw in a C++ library. However, it doesn't qualify as a WTF mainly because it is one of the best-known C++ libraries in one of the best-known C++ library sets, so it's gotta be good:

    http://www.boost.org/doc/libs/1_41_0/boost/bind/bind.hpp

    Tags: TRWTF is C++

  • RHenningsgard (unregistered) in reply to gus

    Exactly.

  • David (unregistered)

    As everyone already said: Use of params would chop that code down to size. Although, it really shouldn't be needed, since parameters arrays are infact, arrays. captcha: "uxor", as in "u haxor".

  • Nick (unregistered) in reply to Neville Flynn
    Neville Flynn:
    frits:
    Neville Flynn:
    At least he seems to understand method overloading, and didn't opt for CreateOneObjectArray, CreateTwoObjectArray, CreateThreeObjectArray, ...

    FTFY

    Bah, that's like me saying "vehicle" and you saying I should have used the word "truck". :P

    Wow. This, right here, is TRWTF for today.

    You can all go home now.

  • (cs)

    That sir is the core of the Javascript. All other Javascript functionality originates in that one portion of the code. How it does, no one knows. It is not our place to inquire on the origin of the Javascript, we are mere mortals who use it as our tool.

  • (cs) in reply to Zylon
    Zylon:
    dkf:
    But this is Javascript, which doesn't partition the world into “values on the stack” and “values in the heap”.
    Oh really? Where's this version of Javascript that supports the "public" and "static" keywords?
    Crud. C# then. (I knew it wasn't Java or C++.) My bad.

    Still doesn't do complex partitioning of the world into stack and heap, which was my real point. Of real languages that are in extensive use today, only C and C++ (plus assembler, of course, though there's no real need to have either heap or stack there) split the world of values into heap and stack. C is known to be low-level and has its strong niche there, but C++ is an odd beast that tries to be all things to all men (and in so doing, fails; languages are defined by their restrictions and omissions).

  • your name* (unregistered) in reply to Death
    Death:
    Forgetting syntax ok... Collecting the common but easy to forget snippets, printing them out and sticking to my wall as a cheat sheet is what most people do about it. If its really bad you can put the snippets in the code as comments if you remember to clean them up later. Writing a workaround right in the code is ... not even a third choice.

    so, if someone forgets syntax, they print it out and stick it to your wall? Does that help them?

  • Anonymous (unregistered) in reply to Ari
    Ari:
    This is correct. I can confirm because we built the same thing at DoubleClick. My guess is that Atlas stole it from us.
    FYI, I hate you and all your kind. I'm wishing cancer upon you and your family right now. I hope it kills you slowly and painfully. I am not joking.
  • (cs) in reply to HurrDurr

    Hey, look. Slashdot is running a story right now about how Eolas's previous victory convinced them that it's time to sue everyone on the planet.

  • Bryan W (unregistered)

    Isn't it obvious why he's creating array objects through functions like that? It's because of the editors. Most of the editors out there, if you want to create an array and you don't know the syntax, you're kind of screwed. You'd have to call up MSDN documation or something to figure it out. But if you create a single function that does it for you, then remember the name, when you type in the name IN THE EDITOR, it will instantly provide the syntax for you to work with the function.

    I've done this stuff before and it makes everything SOOOOO much easier! When you've used 20-30 different languages in a professional environment over the past 15 years, it can get a little tricky trying to remember the exact syntax without a little assistance.

  • Bryan W (unregistered) in reply to Anonymous

    So Anonymous.....this ought to be interesting.....are you suggesting that the hundreds of thousands of Internet advertisers out there (we're pretty much talking every business on the planet) should not try to measure the success of their own advertising? Are we supposed to just start shooting blind?

    FYI, it was companies like DoubleClick that brought about the success of the Internet by increasing advertising success exponentionally! Trust me, without DoubleClick, GOOGLE WOULD NOT EXIST TODAY! Google's business model today can be traced to online advertising models created by companies like DoubleClick. In fact, in the first few years before Google switched over to the PPC model, they were considered to be somewhat of a failure (that whole necessity to earn a profit thing is a real bitch). Like tens of thousands of other companies, Google finally realized that offering everything for free won't make you any money.

    Everybody that earns a living on the Web owes their careers to DoubleClick, Overture, and a handful of other pioneering companies.

  • Anonymous (unregistered) in reply to Bryan W
    Bryan W:
    So Anonymous.....this ought to be interesting..... <Snipped completely unrelated nonsense>

    Everybody that earns a living on the Web owes their careers to DoubleClick, Overture, and a handful of other pioneering companies.

    I have absolutely no idea what you're droning on about. Ali from DoubleClick killed my dog and I've had a vendetta against the guy ever since. Please don't stick your nose into matters you know nothing about, there has already been enough collateral damage in this battle and God knows you won't be missed as much as some of the others. They were fine men, you're just a nobody internet commenter.

  • Jon (unregistered) in reply to dkf

    This isn't true, at all.

    In C#, there are "reference-types" which are stored on the heap. These are objects, and primitives created with the new keyword.

    There are also "value-types" which are stored on the stack. This would be things like primitives (int, string, etc), as well as the variables that reference objects on the heap.

    Value-types are destroyed when their stack frame is popped (thereby giving us scope). Reference-types are garbage collected at some point after there are no more references to them on the stack.

    The differentiation between the stack and heap is still important in C#.

  • frits (unregistered) in reply to Jon
    Jon:
    This isn't true, at all.

    In C#, there are "reference-types" which are stored on the heap. These are objects, and primitives created with the new keyword.

    There are also "value-types" which are stored on the stack. This would be things like primitives (int, string, etc), as well as the variables that reference objects on the heap.

    Value-types are destroyed when their stack frame is popped (thereby giving us scope). Reference-types are garbage collected at some point after there are no more references to them on the stack.

    The differentiation between the stack and heap is still important in C#.

    Arrays (System.Array) are always value types. The stack is irrelevant.

  • frits (unregistered) in reply to frits
    frits:
    Jon:
    This isn't true, at all.

    In C#, there are "reference-types" which are stored on the heap. These are objects, and primitives created with the new keyword.

    There are also "value-types" which are stored on the stack. This would be things like primitives (int, string, etc), as well as the variables that reference objects on the heap.

    Value-types are destroyed when their stack frame is popped (thereby giving us scope). Reference-types are garbage collected at some point after there are no more references to them on the stack.

    The differentiation between the stack and heap is still important in C#.

    Arrays (System.Array) are always value types. The stack is irrelevant.

    reference types.

    FTFM

  • Stefan (unregistered) in reply to Vlad Patryshev

    Agreed. As well as proxying for debugging and compression, you could change the meaning entirely if attempting a refactor, or something similar.

    function DocumentDotWrite(t){ $('#myDiv').append(t) };

    for example.

  • j (unregistered) in reply to QuestionMark
    QuestionMark:
    Severity One:
    That can actually be done much easier and cleaner: 
    public static object[] CreateObjectArray(object ... o)
{
    return o;
}

    There, fixed it for you.

    Maybe I'm off base a little bit, but in the languages I'm used to (C/C++), this would create an array on the stack, which would cause all sorts of hell if you used it later.

    I think the only thing on the stack is a pointer...

  • Pffft! (unregistered) in reply to j
    j:
    QuestionMark:
    Severity One:
    That can actually be done much easier and cleaner: 
    public static object[] CreateObjectArray(object ... o)
{
    return o;
}

    There, fixed it for you.

    Maybe I'm off base a little bit, but in the languages I'm used to (C/C++), this would create an array on the stack, which would cause all sorts of hell if you used it later.

    I think the only thing on the stack is a pointer...

    No. In C and C++, an array is just a chunk of contiguous memory. For automatic storage, that's allocated on the stack. In

    int func(int a){
    int array[16], i, n;
    /* some stuff with a, i, n and array */
    return n;
}

    the array is just 16sizeof(int) bytes on the stack (the address of array[0] is also put on the stack, so it's 16sizeof(int)+sizeof(int*) bytes in total). It would be the same - with different size - for larger arrays, and if you have a compiler which supports it, also for variable-length arrays. Be careful not to cause a stack overflow.

  • undefined (unregistered) in reply to Stefan
    Stefan:
    Agreed. As well as proxying for debugging and compression, you could change the meaning entirely if attempting a refactor, or something similar.

    function DocumentDotWrite(t){ $('#myDiv').append(t) };

    for example.

    In JavaScript you can do document.write=function(t){$('#myDiv').append(t)} because it is the most flexible programming language now.

  • chaz (unregistered)

    the javascript looks like it may be shockwave /flash load hack of some sort. Drill into the codesearch:

    Code search

    I don't really want to make this longer ... sometimes being succinct gets you minus points with akismet ;(

  • chefrocker (unregistered) in reply to gus
    gus:
    There's nothing wrong with that function, IF you want to bottleneck all the document.write() calls, for like, say, debugging or logging.

    Well, except that in JS you could do something like:

    var foo = document.write; document.write = function(str) { doSomeLoggingOrDebugging(str); foo(str); }

    I don't want to call this a generally good idea but way better than writing a wrapper funcion in case you ever might want to add something to a core method.

  • Matt Mastracci (unregistered) in reply to HurrDurr

    That's correct. You also need to call document.write() from an external script as well - it's part of the workaround for the patent.

    The problem here is that the developer didn't leave a comment explaining WTF is going on.

  • Teemu (unregistered) in reply to Bryan W
    Bryan W:
    FYI, it was companies like DoubleClick that brought about the success of the Internet by increasing advertising success exponentionally! Trust me, without DoubleClick, GOOGLE WOULD NOT EXIST TODAY!

    And that would be a good thing. Before the advertisers, the Internet was actually full of useful information.

    Now it's full of facebooks and fashion blogs and whatnot. DoubleClick ruined the internet.

    NOW GET OFF MY LAWN!!!

  • Arjan de Haas (unregistered) in reply to Neville Flynn
    Neville Flynn:
    At least he seems to understand polymorphism, and didn't opt for CreateOneObjectArray, CreateTwoObjectArray, CreateThreeObjectArray, ...

    It's called overloading, not polymorphism.

  • Anonymous Coward (unregistered) in reply to gus

    May have been said before, but hooking document.write for debugging or logging can easily be done by a wrapper function like

    document.prototype.baseWrite = document.prototype.write;

    document.prototype.write = function(arg) { if(document.loggingEnabled) { logCall(); doOtherStuff(); } document.baseWrite(arg); }

    or something

  • anonymous (unregistered) in reply to Anthony
    Anthony:
    Or you had multiple child windows (either frames, iframes or JS popups), and wanted a quick and easy shortcut to write on one of the documents. Then instead of worrying about how to find the primary doc, you just simply call documentDotWrite(s) from anywhere (and document with permissions)... I'm not saying it's neat. I'm not saying it's "good". Just another possible explanation.
    (1) every frame has its own document object, and documentDotWrite() won't be in scope from any other document object than the one it's defined in. If documentDotWrite() is in scope, document.write() will also be in scope (for the same document object).

    (2) document.write() doesn't work like that. It can only be used while the page is loading, and writes to the layout of the page where the script was called. Calling it from an external script wouldn't work unless a script on the page called the external script while the page was loading - when it could have just as easily called document.write().

    What you are thinking of - appending something to the page after it's done loading - could be accomplished with something more like,

    document.body.appendChild(document.createElement("p"))
    .appendChild(document.createTextNode("hello world!"));
    or, if you want to set some attributes, 
    with (document.body.appendChild(document.createElement("p"))) {
    appendChild(document.createTextNode("hello world!"));
    id = "paula";
    className = "brillant";
}
    HurrDurr:
    I'm 90% sure I know what's behind DocumentDotWrite. A couple years ago there was a lawsuit that MS lost about embedding objects in a webpage. http://en.wikipedia.org/wiki/Eolas

    This is exactly the workaround they suggested before they either bought the patent or killed the people behind the nonsense. Notice on the wiki page the "workaround" which is to use javascript to write the object to the DOM instead of embedding it.

    Prove me wrong.

    Really, there's still no good reason why the code couldn't just call document.write()... and if it's really due to some lawsuit stupidity that it has to be done with an external script, why not leave an empty space and then have the external script properly create and insert an Object node of the appropriate type? Using document.write() is a WTF all by itself. An external script containing nothing but a wrapper for document.write() is stupid.

    Anonymous Coward:
    May have been said before, but hooking document.write for debugging or logging can easily be done by a wrapper function like

    document.prototype.baseWrite = document.prototype.write;

    The prototype is Document.prototype, not document.prototype (Javascript is case-sensitive). Furthermore, Document.prototype.write doesn't exist, and defining it has no effect on document.write(). You meant,

    document.baseWrite = document.write;
document.write = function (value) {
    //do something with value here
    return document.baseWrite(value);
};

Leave a comment on “Amazingly Brilliant or Incredibly Stupid”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article