• (nodebb)

    Wait, isn't the first one just a non-terminated recursive method eating up stack till it runs out? I'm curious, because I never attempted to overload in JavaScript, I didn't even know that a redefinition doesn't result in an error.

  • some guy (unregistered)

    One can have sort-of-overloading by type-testing on the duck-typed arguments - but it's not a great idea.

  • (nodebb) in reply to MaxiTB

    Wait, isn't the first one just a non-terminated recursive method eating up stack till it runs out?

    It is, but it never gets called because:

    I'm curious, because I never attempted to overload in JavaScript, I didn't even know that a redefinition doesn't result in an error.

    Indeed. That's ... disappointing, but not entirely unsurprising. It's a bit like all the fun you can have in Python if you carelessly assign a new value to self.frodo when self.frodo exists and is (in theory) a function. The function object disappears and whatever you assigned takes its place.

    $ python
    Python 3.8.10 (default, Sep 11 2024, 16:02:53) 
    [GCC 9.4.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class Furble:
    ...    def frodo(bilbo):
    ...       print("hello")
    ... 
    >>> f = Furble()
    >>> f
    <__main__.Furble object at 0x7f3cf9311fd0>
    >>> f.frodo
    <bound method Furble.frodo of <__main__.Furble object at 0x7f3cf9311fd0>>
    >>> f.frodo = 7
    >>> f.frodo
    7
    

    Luckily:

    >>> del f.frodo
    >>> f
    <__main__.Furble object at 0x7f3cf9311fd0>
    >>> f.frodo
    <bound method Furble.frodo of <__main__.Furble object at 0x7f3cf9311fd0>>
    

    But also:

    ...    def frodo(bilbo):
    ...       print("hello")
    ...    def frodo(baggins,ring):
    ...       print("goodbye")
    ... 
    >>> f = Furble()
    >>> f.frodo()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: frodo() missing 1 required positional argument: 'ring'
    >>> f.frodo("a",7)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: frodo() takes 2 positional arguments but 3 were given
    >>> f.frodo("a")
    goodbye
    >>> del f
    >>> del Furble
    >>> class Furble:
    ...    def frodo(self,bilbo):
    ...        print("hello",bilbo)
    ...    def frodo(self,baggins,ring):
    ...        print("goodbye",baggins,ring)
    ... 
    >>> f = Furble()
    >>> f.frodo("a",7)
    goodbye a 7
    

    So Python does it, too.

  • (nodebb)

    Just as i said yesterday that we have a leading candidate for upper management, competition emerged the very next day.

  • (nodebb)

    The greasy pole has lotsa wannabe's scrabbling at the bottom. And more every day.

  • (nodebb) in reply to Mr. TA

    That's pretty much every day in WTFLand.

  • Scragar (unregistered)

    I doesn't default unpassed in arguments to null, it defaults them to undefined. A similar value, but still distinct.

    null !== undefined , typeof undefined === "undefined" , and typeof null === "object" are all true in JS.

  • Sauron (unregistered)

    That it worked at all was a delightful coincidence

    That the parser accepts it in the first place is heresy.

    Like, in nested scopes why not. But declaring 2 functions with the same identifier in the same scope? The language shouldn't allow that. JS is TRWTF.

  • (nodebb) in reply to Sauron

    JS is definitely very WTFy, but there isn't much choice - that's the language in all the browsers.

    TRWTF is using JS on the server, or using languages like PHP - there are much better choices in that arena.

  • (nodebb)

    it just defaults the remainders to null

    Actually it defaults them to undefined. But that's also falsey, so the logic is the same.

  • (nodebb)

    That senior dev might be thinking of TypeScript, which on the surface does have operator overloading... but only until you compile it down to JavaScript, at which point yeah, it's gone.

    Also, any number of tools would've caught that (ESLint, IDE's). Which makes one wonder what editor that senior dev was using.

  • (nodebb)

    Now that's a silly question.

    Real dev's use Notepad or vi depending on the server OS in use. Running directly on the production server where all edits are made live.

  • Duke of New York (unregistered)

    Fortunately, you don't have to worry about getting a different default value because someone has changed the value of "undefined"... right? right?

  • King (unregistered)

    Javascript in this case feels like IBM 370 Assembly in the 70s. My colleagues used to produce code that modified code, e.g. change a goto to a no op. This was before MMU I guess.

  • (nodebb) in reply to Sauron

    But declaring 2 functions with the same identifier in the same scope? The language shouldn't allow that.

    It didn't. The second definition replaced the first definition. If you wish to revise your argument to "It allowed the running code to change the definition of an existing function? The language shouldn't allow that.", then you're on to something. However, javascript's define-as-you-go behavior was necessary for what its original purpose was. The real WTF is that this language was chosen as the base for modern professional platforms.

  • Randal L. Schwartz (github) in reply to Scragar

    null !== undefined , typeof undefined === "undefined" , and typeof null === "object" are all true in JS.

    I'm soooo happy that Dart, which has transpiling to Javascript as a mandatory goal, did not expose this insanity at the Dart level. You have type bool, with values true and false, as a required type for everything that needs a conditional. You have class Null with a single instance null. And "undefined" does not exist.

  • Your Name (unregistered) in reply to Jaime

    FTFY: The real WTF is that this language was chosen as the base for any platforms.

  • (nodebb) in reply to Randal L. Schwartz

    There are times where the difference between null (deliberately not there) and undefined (just... not there...) are useful. Those times are few and far between, and 99% of the time, null and undefined are handled the same way by your code. (And when you get to JSON, the typical data interchange format, 'undefined' doesn't exist, all is null, and that's well and good, so the weirdness in JS doesn't leak elsewhere.)

    But typeof null === 'object' is godawful. It's even worse when, once upon a time, I had to deal with a JS dialect that didn't throw any kind of exception when you tried to access undefined.undefined.undefined, it just gave you null -- so when I was traversing down a tall object and doing a quick "this last thing exists, right?" check, it would say that yes, I definitely found an object at the bottom of this -- even if I'd typo'd something and was actually holding a null.

  • Daniel Rose (unregistered) in reply to PotatoEngineer

    One case where null vs. undefined is useful is for something like a generic update function. So something like

    function update(obj, newName) { // if newName is undefined, keep the current obj.name // if newName is null, clear obj.name by setting to null if (newName !== undefined) { obj.name = newName; } }

    Note that in JSON, it is also possible to have null vs. undefined:

    { "newName": null } vs. {}

    However, depending on the JSON library and the target programming language, getting the different between these two JSONs may not be easy.

Leave a comment on “An Overloaded Developer”

Log In or post as a guest

Replying to comment #:

« Return to Article