• (nodebb)

    That is the correct use of the word clever

  • dpm (unregistered)

    I would pay good money if this was even close to a WTF in the codebase I inherited. It works and it's intuitive. Now, excuse me while I return to excising the direct calls to the database from the front-end controller . . .

  • (nodebb) in reply to dpm

    I would pay good money if this was even close to a WTF in the codebase I inherited.

    So this would be a "Well, That's Fine" in your codebase, eh ;-) Also, as the saying goes: "i am truley sorry for your lots"

  • (nodebb) in reply to Dragnslcr

    It's more smartass than clever...

  • dpm (unregistered) in reply to The Beast in Black

    I wouldn't say "fine" . . . more like a "Well, that's not worth my time".

  • B11C (unregistered)

    Oh it could be way worse. In Python, for example, you can do something like print(["no", "yes"][some_boolean_variable]). ;)

  • Hal (unregistered) in reply to dpm

    Intuitive?

    Reading thru that code without any familiarity, you don't even pick up on the fact show, hide are functions, you just see a conditional on some string literals. It does not even save any keystrokes from a code golf perspective because it adds the square brackets and the quotes which would not be needed if you just put the () on show and hide inside the ternary statement! Its literally more syntax to interpret for the reader and as bonus requires one to be thinking abstractly about how JavaScript does symbol lookup rather than just considering the control flow itself.

    Honestly this some of the dumbest clever I have seen in a while, because at least most 'clever' code at least save labor for the person who initial authored it. This was just pointless.

  • Robin (unregistered)

    I wouldn't write it that way myself, but this is hardly a WTF. It's perfectly clear what it's doing.

  • Prime Mover (unregistered)

    So TRWTF is not extracting that nugget of functionality into a separate method (or function, or subroutine, or whatever the term is in that language)?

  • Sole Purpose Of Visit (unregistered) in reply to Hal

    Looks perfectly fine to me. If you are proficient in JavaScript then (1) I pity you and (2) this is about as clear a solution as you could hope for.

    Not a WTF, unless somehow the platform changes the keys "show" and "hide" to "arglefargle" and "filenotfound." In which case the stringification comes back to bite you. But hardly a likely eventuality.

  • (nodebb)

    I agree, with no familiarity the use of "on" for the name of the boolean in a language that I'm used to seeing handle events would likely have me initially thinking "...on show or hide of what, do what?!"

    ...That wouldn't be much less of an issue with the ternary, though. But then, my intermittent relationship with Javascript may be unusually strongly associated with this kind of thing, since I consider it an important strength of the language. Not the ability to do this, which I agree is kind of silly, but the characteristics that make it possible to do this.

  • IA (unregistered)

    Avoiding duplicate code at it's best :-)

  • Abigail (unregistered)

    Oh, I never knew that was possible in Javascript (probably because I don't often write Javascript). But this is a trick I will remember, and I wouldn't be ashamed to use it.

  • (nodebb)

    it's the equivalent of this monstrosity in C:

        (condition ? func1 : func2)(args);

    or this really ugly monstrosity in C++

        objectptr->*(condition ? &ClassOfObjet::func1 : &ClassOfObjet::func2)(args);
  • (nodebb)

    We all know the right way to write it is:

    (on?d.show:d.hide)();
  • WTFGuy (unregistered)

    Color me an old fart, but I preferred the days when their was a clear separation between "statements" and "expressions".

    Now we have expressonized statements and statementized expressions. And CS being what it is, that leads almost directly and inevitably to expressionized statementized expressionized statementized expressions. Left associatively. Of course. Used within ternaries. Which someone will claim is "cleaner" or "clearer" because it contains one fewer keystroke or (more commonly) two fewer newlines.

    Maybe we should all just switch to APL. At least it was designed to be terse/fluid. Unlike the various C-like syntaxed languages of today that just had it bolted awkwardly onto the side of the language's head like a conjoined birth-defective mini-Me.

    Bah humbug! Get off my virtual lawn!

  • cc (unregistered)

    Why'd they even bother with the ternary? Concern on type-checking? Seems like the true smartass way to do it would have been: don;

  • a cow (not a robot) (unregistered)

    I can't understand why you seem to hate the "ternary" operators, and always mark as "WTF" their use...

  • DrPepper (unregistered)

    Instead of all of this, change 'd' and the 'show' method:

    d.show(on) -- where show handles the true (show) and false (hide) case.

    Or, if you CAN'T do that:

    (on ? d.show : d.hide)()

  • Klimax (unregistered) in reply to Steve_The_Cynic

    That's why std::function exist… And I implemented similar fun in C++ for dynamic dispatch and accessing variables. (I need to just use std::any for final version ;) )

  • Giulio (unregistered)

    Not sure how I feel about it. It is compact. It does capture that the called object is independent from the condition, while the called function is dependent. It's an uncommon syntax, but it's a legitimate syntax, not like they're eval-ling random stuff or cycling through json.

  • Raphael (unregistered)

    Haha, I recognise myself in this: used to do this all the time. Most of the time with jQuery instances. Which is funny because there’s also a toggle method that takes an argument to either force the elements to show or hide.

  • (nodebb) in reply to Sole Purpose Of Visit

    I am also made about the stringiness because then my IDE can't navigate to the function definition.

    Don't laugh at me! There are dozens of us!

  • (nodebb) in reply to DrPepper

    JS quiz: which of these lines is actually dangerous?

    (on ? d.show() : d.hide())
(on ? d.show : d.hide)()
(d[on ? 'show' : 'hide')()

    The correct answer is 2, which is safe only if the function is not an unbound method. That's because javascript uses a syntactically bound this: it binds whatever was before a . or () to this.

  • Lexi "Big Cheese" (unregistered) in reply to DrPepper

    or make a setter, which i'm pretty sure you can do in javascript, so it'd look more like

    d.visibility = on

  • löchlein deluxe (unregistered)

    Well, at least it's not (on && "show" || "hide"). I'm not sure if long-form boolean operators (on and "show" or "hide") would make this better or worse. At least it's not afterthought-conditionals a la ("show" if on else "hide") or ("hide" unless on else "show").

  • FTB (unregistered)

    If only the "show" function could accept a boolean value...

    The real WTF is calling a jQuery function "JavaScript" in 2023.

  • FTB (unregistered) in reply to Lexi "Big Cheese"

    No, there's no "setters" in JavaScript.

  • Marian (unregistered)

    I don't feel this is particularly /clever/. But it is /pretty/ in a strange way.

  • Foo AKA Fooo (unregistered) in reply to B11C

    Well, in C you can do bool_var["NY"] since "a[b]" ist just sugar for "*(a+b)" and "+" is commutative.

  • NoLand (unregistered)

    In all fairness, this should be really,

    d[(on && 'show') || 'hide']();

Leave a comment on “Terning On a Control”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article