4 ms·

> despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation Tha

> despite one piece of code making a method private, another piece of code still overrides it/modifies it/calls it, an affront to the idea of encapsulation That's inherent on the way current computers manage the memory. And I don't know if the gains are enough to pay for the loses of guaranteeing encapsulation. One could reach for static analysis, but that would imply some restrictions on the machine's assembly. Those are probably worth it. > a piece of code has different behavior depending on the identity of a function I have written my quota of "find the latest caller on the stack with property X, verify if it has access", on different languages. Some times a function can't in any way be just a function.

btown 1y ago
There's also the good old use case of "am I dealing with a subclass that overrode the superclass's implementation of the method." How do you distinguish between a superclass that always returns null/noop, vs. a subclass that happened to return null in this specific case? Sometimes this is useful/vital for setting expectations to the user what functionality the instance is likely to have. Now, you could refactor everything to have the superclass's implementation either throw a NotImplementedError, or return a sentinel value... but changing every call site might be a gargantuan task. Similarly, adding static metadata to every subclass might not be feasible. But checking whether the function's (pre-bound) identity is different is a very easy hack! Ironically, this might indeed be exactly what Apple is doing here, and they're doing it in a tight loop.
- 1718627440 1y ago
  Couldn't you use isinstance(), which would not be a hack?
  - btown 1y ago
    isinstance only tells you which subclass, not whether that subclass overrides the superclass implementation!
ryandrake 1y ago
I don’t understand what goes through the developer’s mind. A method is marked as private. It’s documented as not to be used by developers. Further documentation says that using it may break your application in strange ways now or in the future. Despite all this, the developer concludes: “yea, I think it’s a good idea to use this API!” Then, later when something breaks, it’s Shocked Pikachu all around.
- stalfosknight 1y ago
  And there are people who's default setting is to hate/blame Apple because it's fashionable to do so and they are defending not just the use of but also overriding an API explicitly marked as private. I don't get it.
  - Wowfunhappy 1y ago
    Apple does also break public APIs, so it goes both ways. I will blame Apple when they are blameworthy and not when they are not.
  - merlindru 1y ago
    It's not necessarily "blaming", more a combination of: - Apple released macOS 26 - This version was in testing for many months - During this time, Apple has apparently not tested how Slack, VSCode, Discord, work - Or they have, but haven't bothered to reach out to Electron maintainers - The overriding of the private API was in order to fix a bug with a public one Combine all of these and there is some onus on Apple for this. If you don't fix your broken public APIs, don't be surprised when people start using your private ones that do work. But easily the worst point is that QA apparently is limited to their own applications only. Do they really care about the user if they don't test applications found on nearly every mac setup out there? Don't they use Slack internally?!
    - Someone 1y ago
      How come this only surfaces now? Surely large companies such as Microsoft and Slack apparently tested their products that use Electron with the public betas?
kccqzy 1y ago
I have written my share of "inspect caller and do things" too. I still don't like that.
- marcosdumay 1y ago
  Personally, at this point I blame that universal assumption that every piece of code inside a program has the same reliability, trustworthiness and disclosure properties. At some point we'll have to burn down every bit of software infrastructure and build it new with some care about security.
1718627440 1y ago
> That's inherent on the way current computers manage the memory. You can trivially do that today by telling the linker to discard this symbol. Sure it's still not hardware isolation, but now the caller needs to disassemble the binary and hardcode locations. When its inlined before, then you aren't even able to do this.

btown 1y ago

There's also the good old use case of "am I dealing with a subclass that overrode the superclass's implementation of the method." How do you distinguish between a superclass that always returns null/noop, vs. a subclass that happened to return null in this specific case? Sometimes this is useful/vital for setting expectations to the user what functionality the instance is likely to have. Now, you could refactor everything to have the superclass's implementation either throw a NotImplementedError, or return a sentinel value... but changing every call site might be a gargantuan task. Similarly, adding static metadata to every subclass might not be feasible. But checking whether the function's (pre-bound) identity is different is a very easy hack! Ironically, this might indeed be exactly what Apple is doing here, and they're doing it in a tight loop.

1718627440 1y ago
Couldn't you use isinstance(), which would not be a hack?
- btown 1y ago
  isinstance only tells you which subclass, not whether that subclass overrides the superclass implementation!

ryandrake 1y ago

I don’t understand what goes through the developer’s mind. A method is marked as private. It’s documented as not to be used by developers. Further documentation says that using it may break your application in strange ways now or in the future. Despite all this, the developer concludes: “yea, I think it’s a good idea to use this API!” Then, later when something breaks, it’s Shocked Pikachu all around.

stalfosknight 1y ago
And there are people who's default setting is to hate/blame Apple because it's fashionable to do so and they are defending not just the use of but also overriding an API explicitly marked as private. I don't get it.
- Wowfunhappy 1y ago
  Apple does also break public APIs, so it goes both ways. I will blame Apple when they are blameworthy and not when they are not.
- merlindru 1y ago
  It's not necessarily "blaming", more a combination of: - Apple released macOS 26 - This version was in testing for many months - During this time, Apple has apparently not tested how Slack, VSCode, Discord, work - Or they have, but haven't bothered to reach out to Electron maintainers - The overriding of the private API was in order to fix a bug with a public one Combine all of these and there is some onus on Apple for this. If you don't fix your broken public APIs, don't be surprised when people start using your private ones that do work. But easily the worst point is that QA apparently is limited to their own applications only. Do they really care about the user if they don't test applications found on nearly every mac setup out there? Don't they use Slack internally?!
  - Someone 1y ago
    How come this only surfaces now? Surely large companies such as Microsoft and Slack apparently tested their products that use Electron with the public betas?

kccqzy 1y ago

I have written my share of "inspect caller and do things" too. I still don't like that.

marcosdumay 1y ago
Personally, at this point I blame that universal assumption that every piece of code inside a program has the same reliability, trustworthiness and disclosure properties. At some point we'll have to burn down every bit of software infrastructure and build it new with some care about security.

1718627440 1y ago

> That's inherent on the way current computers manage the memory. You can trivially do that today by telling the linker to discard this symbol. Sure it's still not hardware isolation, but now the caller needs to disassemble the binary and hardcode locations. When its inlined before, then you aren't even able to do this.