3 ms·

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 (

by dvt 1y ago

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).

rowanG077 1y ago
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.
- dvt 1y ago
  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.
  - JoshTriplett 1y ago
    You started with "In no language has a variable assignment ever stopped execution", and now you're saying "The assignment operator is not supposed to have side-effects". location.href is a counterexample, and there are many counterexamples throughout various tools and languages and libraries. Deciding how you think things should work does not affect how things do work, and it's important to understand the latter. (I do agree it's bad practice, but it happens and people do not always fully control the environments they must work with.) And given that location.href does have a side effect, it's not unreasonable for someone to have assumed that that side effect was immediate rather than asynchronous. That said, if you don't like working with such languages, that's all the more reason to select languages where that doesn't happen, which comes back to the point made in the article.
    - dvt 1y ago
      > You started with "In no language has a variable assignment ever stopped execution", The irony is that I'm still technically correct, as literally every example (from C++, to C#, to Python, to JS) have been object property assignments abusing getters and setters—decidedly not variable assignments (except for the UB example).
      - rowanG077 1y ago
        The entire discussion is about a property assignment. Which in colloquial usage is also called variable assignment. Which is obvious since nobody corrected you on that. You now trying to do a switcheroo is honestly ridiculous.
        dvt 1y ago
        The entire discussion is about “=“ doing weird stuff, which in 99.9% of cases it does not do. And my point was that no language, without doing weird stuff (like overloading), does not let “=“ do weird stuff (and thus is pure). The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.
        JoshTriplett 1y ago
        > The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default. That sounds like a recipe for having problems every time you encounter a nonstandard contract. Are you actually saying you willfully decide never to account for the possibility, or are you conflating "ought not to be" with "isn't"? If I'm programming in a language that has the possibility of properties, it's absolutely a potential expectation at any time. Which is one reason I don't enjoy programming in such languages as much. To give a comparable example: if I'm coding in C, "this function might actually be a macro" is always a possibility to be on guard against, if you do anything that could care about the difference (e.g. passing the function's name as a function pointer).
  - kketch 1y ago
    assignments are side effects, even more so when they are done through a setter on an object / class instance
  - toast0 1y ago
    > The assignment operator is not supposed to have side-effects, Memory mapped I/O disagrees with this. Writing a value can trigger all sorts of things.
  - jibal 1y ago
    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.
dminik 1y ago
But window.location.href is already an overloaded setter. It schedules a page navigation.

by dvt 1y ago

rowanG077 1y ago

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.

dvt 1y ago
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.
- JoshTriplett 1y ago
  You started with "In no language has a variable assignment ever stopped execution", and now you're saying "The assignment operator is not supposed to have side-effects". location.href is a counterexample, and there are many counterexamples throughout various tools and languages and libraries. Deciding how you think things should work does not affect how things do work, and it's important to understand the latter. (I do agree it's bad practice, but it happens and people do not always fully control the environments they must work with.) And given that location.href does have a side effect, it's not unreasonable for someone to have assumed that that side effect was immediate rather than asynchronous. That said, if you don't like working with such languages, that's all the more reason to select languages where that doesn't happen, which comes back to the point made in the article.
  - dvt 1y ago
    > You started with "In no language has a variable assignment ever stopped execution", The irony is that I'm still technically correct, as literally every example (from C++, to C#, to Python, to JS) have been object property assignments abusing getters and setters—decidedly not variable assignments (except for the UB example).
    - rowanG077 1y ago
      The entire discussion is about a property assignment. Which in colloquial usage is also called variable assignment. Which is obvious since nobody corrected you on that. You now trying to do a switcheroo is honestly ridiculous.
      - dvt 1y ago
        The entire discussion is about “=“ doing weird stuff, which in 99.9% of cases it does not do. And my point was that no language, without doing weird stuff (like overloading), does not let “=“ do weird stuff (and thus is pure). The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default.
        JoshTriplett 1y ago
        > The counterarguments all involve nonstandard contracts. Therefore, thinking that using “=“ will have some magical side-effect is absolutely never expected by default. That sounds like a recipe for having problems every time you encounter a nonstandard contract. Are you actually saying you willfully decide never to account for the possibility, or are you conflating "ought not to be" with "isn't"? If I'm programming in a language that has the possibility of properties, it's absolutely a potential expectation at any time. Which is one reason I don't enjoy programming in such languages as much. To give a comparable example: if I'm coding in C, "this function might actually be a macro" is always a possibility to be on guard against, if you do anything that could care about the difference (e.g. passing the function's name as a function pointer).
- kketch 1y ago
  assignments are side effects, even more so when they are done through a setter on an object / class instance
- toast0 1y ago
  > The assignment operator is not supposed to have side-effects, Memory mapped I/O disagrees with this. Writing a value can trigger all sorts of things.
- jibal 1y ago
  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.

dminik 1y ago

But window.location.href is already an overloaded setter. It schedules a page navigation.