←back to thread

517 points bkolobara | 1 comments | | HN request time: 0.205s | source
Show context
merdaverse ◴[] No.45043051[source]
Code written below your line gets executed if you don't return early. More breaking news at 8.

Seriously, why would you think that assigning a value would stop your script from executing? Maybe the Typescript example is missing some context, but it seems like such a weird case to present as a "data race".

replies(8): >>45043245 #>>45043339 #>>45043398 #>>45043537 #>>45043876 #>>45046033 #>>45046975 #>>45049155 #
lights0123 ◴[] No.45043339[source]
exit(), execve(), and friends do immediately stop execution—I could understand why you'd think a redirect would as well.
replies(4): >>45043409 #>>45043410 #>>45049020 #>>45049406 #
dvt ◴[] No.45043410[source]
The redirect is an assignment. In no language has a variable assignment ever stopped execution.
replies(6): >>45043422 #>>45043544 #>>45043663 #>>45043805 #>>45047504 #>>45047601 #
JoshTriplett ◴[] No.45043544[source]

    $ python3
    Python 3.13.7 (main, Aug 20 2025, 22:17:40) [GCC 14.3.0] on linux
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class MagicRedirect:
    ...     def __setattr__(self, name, value):
    ...         if name == "href":
    ...             print(f"Redirecting to {value}")
    ...             exit()
    ... 
    >>> location = MagicRedirect()
    >>> location.href = "https://example.org/"
    Redirecting to https://example.org/
    $
replies(1): >>45045418 #
dvt ◴[] No.45045418[source]
You're overloading a setter here. It's cute, I did it in JS as well, but I don't really think it's a counterexample. It would be odd to consider this the norm (per the thought process of the original blog post).
replies(2): >>45045557 #>>45045946 #
rowanG077 ◴[] No.45045557[source]
This is not some weird thing. Here is a run of the mill example where python can have properties settting do anything at all. And it's designed like that.

    import sys
    
    class Foo:
        @property
        def bar(self):
            return 10
            
        @bar.setter
        def bar(self, value):
            print("bye")
            sys.exit()
    
    foo = Foo()
    foo.bar = 10
Or in C# if you disqualify dynamic languages:

    using System;

    class Foo
    {
        public int Bar
        {
            get { return 10; }
            set
            {
                Console.WriteLine("bye.");
                Environment.Exit(0);
            }
        }
    }

    class Program
    {
        static void Main()
        {
            Foo obj = new Foo();
            obj.Bar = 10;
        }
    }

This is not some esoteric thing in a lot of programming languages.
replies(1): >>45046687 #
dvt ◴[] No.45046687[source]
You're also overriding a setter. Maybe I'm going against the grain here, but it's absolutely esoteric. The assignment operator is not supposed to have side-effects, and maybe this is the logician in me, but the implication that we should be aware that weird stuff might be happening when we do `x = 5` is fundamentally bonkers.
replies(4): >>45046718 #>>45047382 #>>45048993 #>>45050028 #
1. jibal ◴[] No.45050028[source]
Assignment is by definition a side effect.

This whole discussion is completely off kilter by all parties because setting the variable doesn't terminate the script--that's the bug; it simply sets the variable (that is, it sets a property in a globally accessible structure). Rather, some time later the new page is loaded from the variable that was set.

Aside from that, your comments are riddled with goalpost moving and other unpleasant fallacies and logic errors.

FWIW I grew up in the days (well, actually I was already an adult who had been programming for a decade) when storing values in the I/O page of PDP-11 memory directly changed the hardware devices that mapped their operation registers to those memory addresses. That was the main reason for the C `volatile` keyword.