6 ms·

https://github.com/electron/electron/issues/48311#issuecomment-3332181420 https://github.com/electron/electron/issues/48311#issuecomme... If this comment is to

• wk_end 1y ago
  "Not Apple's fault" is up for debate; even if Electron shouldn't be doing this, Apple arguably shouldn't be pushing out updates that cause issues with wide-swaths of software that users use regardless.
  • tom1337 1y ago
    So you're blaming because they've changed a private API which electron not only used, but also seemed to have patched?
    • asqueella 1y ago
      No, for "pushing out updates that cause issues [with very common software]".
      • smashedtoatoms 1y ago
        As a dev, if you use a private method, you've just taken ownership of the problem. I suggested to you in our contract not to do it, and that it would likely not be supported, and you did it anyway. Fix your shit, common software or not.
        • asqueella 1y ago
          This is what an Apple engineer could write in the electron's github issue if they refused to fix it. We're not discussing that, but that they have pushed an update without proper testing. You can see from the other comments that breakage is not limited to people using private methods.
  • pavlov 1y ago
    That’s the principle that prevented Windows from making any meaningful progress for the past three decades.
    • wk_end 1y ago
      What? Windows made tons of progress while maintaining this principle and became the most popular operating system in the world. Are you trying to tell me that you believe the evolution of Windows from 1.0 all the way to 7 - the entire time trying to operate according to this principle - doesn't constitute meaningful progress? The recent stagnation of the OS has nothing to do with attempting to maintain backwards compatibility.
      • acdha 1y ago
        It’s true that they’ve made some progress but my work laptop running Windows 11 still has UI elements from Windows 95/NT 4. The file system hasn’t improved since then and the keyboard responsiveness is actually worse. BeOS on 90s hardware absolutely torches Windows 11 on things like UI responsiveness, ability to multitask without degrading UI performance, and the file system (not networking, of course, it wasn’t perfect). I think it’s fair to question whether the decisions around backwards compatibility have been worth the cost but I’d imagine they’re already doing that. Enterprise IT departments love Windows but nobody else does, and the generation of people who grew up using iOS/Android and macOS/ChromeOS for school aren’t going to jump at the chance to bring that enterprise IT experience into their personal lives.
        • cyberax 1y ago
          You can actually tell the old controls from the Win NT by how fast and responsive they are. They also properly follow the best practices by showing keyboard accelerators when you press "alt". It's the new stuff that is slow and unusable.
          • 1718627440 1y ago
            And they also explain themself to the user. The new UI often doesn't tell you at all, what exactly you are modifying here, while the old often has paragraphs of explanation.
  • cosmic_cheese 1y ago
    Apple’s attitude here is that it’s an inherent risk of using private APIs, because it’s not something they want devs doing. They don’t facilitate it like MS tends to. Don’t touch the stove if you don’t want to get burnt.
    • wk_end 1y ago
      The person who's getting burnt is Random Officer Worker Joe, who just wants to run Slack and Spotify and who doesn't know a thing about Electron or private APIs, but knows that ever since upgrading their version of macOS things are running terribly. Apple's position is technically noble, but that doesn't help their users.
      • cosmic_cheese 1y ago
        The Electron maintainers should've considered that possibility before reaching for a private API. It's on the Electron's team's shoulders and nobody else's. If I were building a FOSS platform, I wouldn't give a second thought to third parties making use of my platform's private APIs. They're private for a reason, whether that be because they're not yet fully baked or because using them can have unintended consequences, they're not intended for public consumption. I especially wouldn't want somebody else's platform to depend on my private APIs, because I am then effectively locked into keeping that API frozen in time by the numerous others building on this other person's platform. It's generally poor practice to build upon such brittle things as under-the-hood tinkering anyway.
      • Aaargh20318 1y ago
        > Apple's position is technically noble, but that doesn't help their users. The alternative doesn’t help either. That’s the approach Microsoft has taken and look what a mess Windows is because of it.
        • viraptor 1y ago
          > what a mess Windows is because of it. Can you point at any part of windows being a mess specifically because of backwards compatibility?
  • Aurornis 1y ago
    We've had developer betas of macOS Tahoe since June. Standard practice for any mobile or desktop software is to start testing on the betas as soon as they're available. Unless this was a last-minute change before the final release, it's on the software developers to use the betas to prepare their software for upcoming releases.
    • Tteriffic 1y ago
      Exactly. Who you blame depends on if it was introduced in beta 1 or RC.
• cosmic_cheese 1y ago
  A good argument for allowing and working with minor platform differences instead of trying to micromanage every little aspect to force inter-platform consistency and/or perfect compliance with the mockup.
• x0x0 1y ago
  Nah, it's Apple's fault. Not regression testing against major apps is pure incompetence. Also, this in the comment: > [a user] Please try any way of getting in touch with Apple engineers you can. As a project, we don't have a better connection to Apple than you do. > > One approach might be the engineer who replied to the Bluesky post that someone linked to above about the input issue. Pure incompetence. Major projects have no way to do anything but ping randoms on socials.
  • bombcar 1y ago
    This is downvoted, but it's true. It doesn't matter who's fault it is in some Aristotelean sense, what matters is the user upgraded to YOUR new OS, and now shit don't work. Raymond Chen and Microsoft got this, years ago. Joel talked about it. You make shit work, even if it's the software being a fuck.
    • kridsdale3 1y ago
      No time to do that when you need to re-do the entire UI of 100 apps for no good reason other than to make an iMac indistinguishable from an iPad.
    • sgerenser 1y ago
      Or, as some OS maintainer once said: WE DO NOT BREAK USERSPACE! Seriously. How hard is this rule to understand? We particularly don't break user space with TOTAL CRAP.
      • aw1621107 1y ago
        This situation seems to be more analogous to an out-of-tree driver which reaches into kernel internals, which Linux does break all the time.
        • mrheosuper 1y ago
          if the out-of-tree driver does not touch kernel space, it should not be broken.
• marcosdumay 1y ago
  > 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
• SkiFire13 1y ago
  > (2) a piece of code has different behavior depending on the identity of a function, contrary to the principle of extensionality. Note that most definitions of extensionality don't consider the number of steps to achieve the result as an observable property, although in practice it is.
• snarfy 1y ago
  It's all pretty terrible. For problem (1) why does the language allow it? And why are they doing it this way? Did Apple not provide an official way?
  • cosmic_cheese 1y ago
    With Objective-C's nature as a dynamic language, there's no way to make APIs fully private and unusable to third parties. Despite heavily embracing Swift in recent years, much of AppKit and UIKit are still written in Objective-C.
• cyberax 1y ago
  Abuse of private APIs means that your public API is incomplete. And that people dislike how your system behaves so much, that they're willing to muck with its internals.
  • stalfosknight 1y ago
    No, it means some people are doing it wrong either because: 1. They don't know how to do it the right way or 2. They can't be bothered to do it the right way #1 I can understand. We all make mistakes as we learn and grow as developers. #2 is just arrogance / laziness on the part of the developer. Compounding it by blaming the platform owner that clearly and explicitly told you not to go that route is gross.
    • cyberax 1y ago
      [flagged]
      • stalfosknight 1y ago
        I'll grant that their documentation isn't the best I've ever seen, but it is still on you if you reach for private APIs. Again, that is consciously choosing a shortcut you've been explicitly told not to use.
      • epistasis 1y ago
        From the bug report: > It turns out Electron was overriding a private AppKit API (_cornerMask) to apply custom corner masks to vibrant views. > ... > By removing the custom _cornerMask override and associated logic, we allow AppKit to handle shadows with its default pipeline. This resolves the GPU spike while retaining shadows as expected. I'd say that most often usage of private APIs is because: 4. it probably shouldn't be done at all
        • merlindru 1y ago
          I don't know what the comment you're replying to said, but further down the thread: > Electron's "_cornerMask" override was a dirty hack that was made in an effort to fix an ancient issue with corner smoothing. So Electron used this private API to fix an issue that shouldn't have existed at all, as far as I can tell
• 1718627440 1y ago
  > (1) 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 why its a good idea to strip a symbol or provide a linker script. This way you can also properly version the code.
• Zanfa 1y ago
  To be fair, AppKit is buggy/undocumented enough that you need to muck with the internals even for trivial things.
• tyteen4a03 1y ago
  Reminds me of this line of code where Apple included a symbol just to please an app (which happens to be WeChat, the largest IM app in China): https://github.com/apple-oss-distributions/libmalloc/blob/13aaf4cb0a58d49bf649743e1406e64a573ad944/private/make_tapi_happy.h#L110 https://github.com/apple-oss-distributions/libmalloc/blob/13...