12 ms·

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

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?
    - mikamika83 1y ago
      It's very hard to notice and very easy to attribute something else. The main symptom is your laptop heating up which is usually attributed to (1) You just have a slow MacBook, you should get a new one (2) During beta, "it's a beta and it's expected to heat up and be slow" (3) People not caring about temps because they use the laptop in clamshell mode I believe this falls into the perfect definition of "slipped thru the cracks"
cyberax 1y ago
Yeah, but you HATE how the system behaves because some great spark at Apple thought that corners must always be _this_ rounded.
thfuran 1y ago
The alternative to using private methods or reflectively mucking about with library/platform internals isn't always "do the same thing but with only public API"; it's sometimes "you can't possibly fix the bug or implement the feature that you want to". It sure does increase maintenance burden though.
- bigstrat2003 1y ago
  > it's sometimes "you can't possibly fix the bug or implement the feature that you want to" Yes. It is, and that is what any responsible person should choose.
  - thfuran 1y ago
    So you'd tell customers "No, I'm not fixing that bug because doing so would offend my aesthetic sensibilities. Yes, I know you have a support contract, but I simply refuse to address your problem even though I could"? Or maybe you'd phrase it a little differently in public.
    - rogerrogerr 1y ago
      “Poor decisions on your part do not constitute an emergency on mine.”
      - willis936 1y ago
        "Poor decisions on a third party's part do constitute an emergency on mine."
    - frumplestlatz 1y ago
      Yes, I have told customers exactly that when there was no supported way to achieve what they wanted. I'm not putting my name on that.
toast0 1y ago
Ok, but > // By overriding this built-in method the corners of the vibrant view (if set) will be smooth. If you don't override the built-in method, the corners won't be smooth. Jagged corners cause thousands of eye injuries every day. Using (or overriding) private APIs comes with risks, but sometimes it's the only way to get things done. Of course, it comes with consequences too. Sometimes vendors test their new releases with commonly use applications and reach out when they've changed things and breakage results, but testing releases isn't webscale.
- merlindru 1y ago
  > Sometimes vendors test their new releases with commonly use applications "common" is an understatement. I'd bet that at least one affected, broken app is on 97%+ of macOS setups
runjake 1y ago
> I don’t understand what goes through the developer’s mind. I'm not defending anyone here, but sometimes it's to work around bugs in public APIs that never get fixed. And sometimes it's because some perceived needed functionality isn't exposed in public APIs. They figure "It'd be a lot easier to use this private API. We can just fix it if it breaks.", not really realizing the ramifications, for example a lot of apps use older versions of Electron -- some even EOL. Is the Electron team now going to backport this fix to several versions back? Sounds... involved.
- merlindru 1y ago
  > to work around bugs in public APIs that never get fixed. According to the commenter who uncovered the cause of the issue, this is exactly what happened here
porridgeraisin 1y ago
> I don't understand Well. This is hardly the funniest example then. Check this one out: https://github.com/reactjs/react.dev/issues/3896 https://github.com/reactjs/react.dev/issues/3896
- deleted 1y ago
  [deleted]
tclancy 1y ago
I get it but a lot of the war stories from Raymond Chen's blog https://devblogs.microsoft.com/oldnewthing/ https://devblogs.microsoft.com/oldnewthing/ were about helping major corporations unscrew something that had relied on a private Windows API because there hadn't been a good way to do it. I would guess most cases of people choosing to rely on a private method are laziness or lack of knowledge about "the right way" (or call it bad documentation), but not 100%.
- igregoryca 1y ago
  Discovering and using private APIs is not a walk in the park. I doubt "laziness" is a common motivation for doing so. Lack of knowledge or bad docs, perhaps. But there's often no officially sanctioned way to do something that people want (and perhaps will pay for) - most private API usage I've seen falls into this third bucket.
  - pdpi 1y ago
    Laziness comes in many forms. Arguably, discovering and using private APIs is a form of intellectual laziness — it requires you to refuse acknowledging that the whole system is telling not to do things that way.
    - onli 1y ago
      If you defer to authority. That is, you accept that the people who made the API have the authority to dictate you what you can or can't do on your hardware (or for other people on their), that privating the parts of the API you need was a conscious decision (and not just laziness on their part) and that in general you listen to commands like that. Even with just a shroud of hacker thinking that is not something programmers should easily accept.
      - tclancy 1y ago
        Oh wow, that is the opposite of Hacker Mentality to me. I may question lots of other people, but if some other coder put in the time to construct a well designed API that includes public and private methods, my first thought is never “I know better”. Took me a couple of decades to stop thinking that though, so what do I know?
whywhywhywhy 1y ago
Apple has to take some of the blame from this, MacOS without Electron apps is a much less useful proposition. If they knew they were going to change this API in this release it would have made sense to reach out and offer a public way to Electron. End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs
- urbandw311er 1y ago
  Absolutely not. Apple has zero responsibility to anybody for changing a private API. That’s the whole point of it being marked private.
  - whywhywhywhy 1y ago
    I disagree I think Apple has a responsibility to not break the biggest software used on their platform. They might not like it but I'm sure they'd dislike that software never being there at all even more.
  - DengistKhan 1y ago
    If one dude is using a private API, that's him being reckless. If thousands of applications are using a private API, that's poor API design.
    - bogantech 1y ago
      The thousands of "apps" wouldn't all be using this private api if they weren't electron junk
mvdtnz 1y ago
> Then, later when something breaks, it’s Shocked Pikachu all around This isn't really true. When something breaks it's generally "darn, we knew it would happen eventually".
grishka 1y ago
Sometimes you just can't achieve something with public APIs. Especially on Apple OSes, they love making genuinely useful APIs private for no good reason while heavily using them in their own apps. Of course, if you use a private API, you're on your own if your app breaks because of it. I myself have done my fair share of using private APIs on Android. Ideally, you should test your app on beta versions of every upcoming major OS release to make sure it doesn't break. Even more ideally, there's a public equivalent starting with some OS version and you only use the private one until that version, then nothing will ever break.
jcelerier 1y ago
If breaking encapsulation delivers value under the form of features-making-users-happy for a couple years and the fix when it breaks is a matter of a couple weeks (and, like here, a line of code) then it's definitely the right tradeoff
DengistKhan 1y ago
In my decade of experience with laravel I've seen ordersof magnitude more public APIs randomly breaking than private ones.

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?
  - mikamika83 1y ago
    It's very hard to notice and very easy to attribute something else. The main symptom is your laptop heating up which is usually attributed to (1) You just have a slow MacBook, you should get a new one (2) During beta, "it's a beta and it's expected to heat up and be slow" (3) People not caring about temps because they use the laptop in clamshell mode I believe this falls into the perfect definition of "slipped thru the cracks"

cyberax 1y ago

Yeah, but you HATE how the system behaves because some great spark at Apple thought that corners must always be _this_ rounded.

thfuran 1y ago

The alternative to using private methods or reflectively mucking about with library/platform internals isn't always "do the same thing but with only public API"; it's sometimes "you can't possibly fix the bug or implement the feature that you want to". It sure does increase maintenance burden though.

bigstrat2003 1y ago
> it's sometimes "you can't possibly fix the bug or implement the feature that you want to" Yes. It is, and that is what any responsible person should choose.
- thfuran 1y ago
  So you'd tell customers "No, I'm not fixing that bug because doing so would offend my aesthetic sensibilities. Yes, I know you have a support contract, but I simply refuse to address your problem even though I could"? Or maybe you'd phrase it a little differently in public.
  - rogerrogerr 1y ago
    “Poor decisions on your part do not constitute an emergency on mine.”
    - willis936 1y ago
      "Poor decisions on a third party's part do constitute an emergency on mine."
  - frumplestlatz 1y ago
    Yes, I have told customers exactly that when there was no supported way to achieve what they wanted. I'm not putting my name on that.

toast0 1y ago

Ok, but > // By overriding this built-in method the corners of the vibrant view (if set) will be smooth. If you don't override the built-in method, the corners won't be smooth. Jagged corners cause thousands of eye injuries every day. Using (or overriding) private APIs comes with risks, but sometimes it's the only way to get things done. Of course, it comes with consequences too. Sometimes vendors test their new releases with commonly use applications and reach out when they've changed things and breakage results, but testing releases isn't webscale.

merlindru 1y ago
> Sometimes vendors test their new releases with commonly use applications "common" is an understatement. I'd bet that at least one affected, broken app is on 97%+ of macOS setups

runjake 1y ago

> I don’t understand what goes through the developer’s mind. I'm not defending anyone here, but sometimes it's to work around bugs in public APIs that never get fixed. And sometimes it's because some perceived needed functionality isn't exposed in public APIs. They figure "It'd be a lot easier to use this private API. We can just fix it if it breaks.", not really realizing the ramifications, for example a lot of apps use older versions of Electron -- some even EOL. Is the Electron team now going to backport this fix to several versions back? Sounds... involved.

merlindru 1y ago
> to work around bugs in public APIs that never get fixed. According to the commenter who uncovered the cause of the issue, this is exactly what happened here

porridgeraisin 1y ago

> I don't understand Well. This is hardly the funniest example then. Check this one out: https://github.com/reactjs/react.dev/issues/3896 https://github.com/reactjs/react.dev/issues/3896

deleted 1y ago
[deleted]

tclancy 1y ago

I get it but a lot of the war stories from Raymond Chen's blog https://devblogs.microsoft.com/oldnewthing/ https://devblogs.microsoft.com/oldnewthing/ were about helping major corporations unscrew something that had relied on a private Windows API because there hadn't been a good way to do it. I would guess most cases of people choosing to rely on a private method are laziness or lack of knowledge about "the right way" (or call it bad documentation), but not 100%.

igregoryca 1y ago
Discovering and using private APIs is not a walk in the park. I doubt "laziness" is a common motivation for doing so. Lack of knowledge or bad docs, perhaps. But there's often no officially sanctioned way to do something that people want (and perhaps will pay for) - most private API usage I've seen falls into this third bucket.
- pdpi 1y ago
  Laziness comes in many forms. Arguably, discovering and using private APIs is a form of intellectual laziness — it requires you to refuse acknowledging that the whole system is telling not to do things that way.
  - onli 1y ago
    If you defer to authority. That is, you accept that the people who made the API have the authority to dictate you what you can or can't do on your hardware (or for other people on their), that privating the parts of the API you need was a conscious decision (and not just laziness on their part) and that in general you listen to commands like that. Even with just a shroud of hacker thinking that is not something programmers should easily accept.
    - tclancy 1y ago
      Oh wow, that is the opposite of Hacker Mentality to me. I may question lots of other people, but if some other coder put in the time to construct a well designed API that includes public and private methods, my first thought is never “I know better”. Took me a couple of decades to stop thinking that though, so what do I know?

whywhywhywhy 1y ago

Apple has to take some of the blame from this, MacOS without Electron apps is a much less useful proposition. If they knew they were going to change this API in this release it would have made sense to reach out and offer a public way to Electron. End of the day the needs of users running Electron apps outweighs whatever opinions the internal Apple team has about their APIs

urbandw311er 1y ago
Absolutely not. Apple has zero responsibility to anybody for changing a private API. That’s the whole point of it being marked private.
- whywhywhywhy 1y ago
  I disagree I think Apple has a responsibility to not break the biggest software used on their platform. They might not like it but I'm sure they'd dislike that software never being there at all even more.
- DengistKhan 1y ago
  If one dude is using a private API, that's him being reckless. If thousands of applications are using a private API, that's poor API design.
  - bogantech 1y ago
    The thousands of "apps" wouldn't all be using this private api if they weren't electron junk

mvdtnz 1y ago

> Then, later when something breaks, it’s Shocked Pikachu all around This isn't really true. When something breaks it's generally "darn, we knew it would happen eventually".

grishka 1y ago

Sometimes you just can't achieve something with public APIs. Especially on Apple OSes, they love making genuinely useful APIs private for no good reason while heavily using them in their own apps. Of course, if you use a private API, you're on your own if your app breaks because of it. I myself have done my fair share of using private APIs on Android. Ideally, you should test your app on beta versions of every upcoming major OS release to make sure it doesn't break. Even more ideally, there's a public equivalent starting with some OS version and you only use the private one until that version, then nothing will ever break.

jcelerier 1y ago

If breaking encapsulation delivers value under the form of features-making-users-happy for a couple years and the fix when it breaks is a matter of a couple weeks (and, like here, a line of code) then it's definitely the right tradeoff

DengistKhan 1y ago

In my decade of experience with laravel I've seen ordersof magnitude more public APIs randomly breaking than private ones.