「Appleのせいじゃない」というのは議論の余地があるね。Electronがこんなことをするべきじゃないとしても、Appleもユーザーが使ってるソフトウェアに問題を引き起こすアップデートを出すべきじゃないと思う。

小さなプラットフォームの違いを許容して、うまくやっていく方がいいっていうのはいい意見だね。すべての細かい部分を管理して、プラットフォーム間の一貫性や完璧なモックアップへの準拠を強制しようとするよりも。

いや、これはAppleのせいだよ。主要なアプリに対して回帰テストをしないのは純粋に無能だと思う。あと、コメントにあったこれね：> [あるユーザー] Appleのエンジニアに連絡を取る方法を試してみてください。プロジェクトとして、私たちはあなたよりAppleとのつながりが良くないです。> > 一つのアプローチとしては、上でリンクされてたBlueskyの投稿に返信したエンジニアに連絡することかも。純粋に無能だよ。大きなプロジェクトは、ソーシャルでランダムな人に連絡するしかない。

あるコードがメソッドをプライベートにしても、別のコードがそれをオーバーライドしたり、修正したり、呼び出したりするのは、カプセル化の考えに対する侮辱だね。これは現在のコンピュータがメモリを管理する方法に内在してる。カプセル化を保証するための損失を補うほどの利点があるかは分からない。静的解析を試みることもできるけど、それはマシンのアセンブリにいくつかの制限を課すことを意味する。多分、それは価値がある。> コードの一部は関数のアイデンティティによって異なる動作をする。俺は「スタック上でプロパティXを持つ最新の呼び出し元を見つけて、それがアクセスできるか確認する」っていうのをいろんな言語でやってきた。時には、関数が単なる関数になれないこともある。

ほんとにひどいね。問題(1)について、なんでその言語がそれを許してるの？ なんでこんなやり方をしてるの？ Appleは公式な方法を提供しなかったのかな？

(2) コードの挙動は関数のアイデンティティによって異なるから、拡張性の原則に反してるよね。ほとんどの拡張性の定義では、結果を得るためのステップ数は観察可能な特性として考慮されてないけど、実際にはそうなんだよね。

プライベートAPIの乱用は、パブリックAPIが不完全であることを意味する。そして、システムの挙動があまりにも嫌われているから、内部をいじりたくなるってことだね。

そうかもしれないけど、この特定のケースはElectron側のプライベートAPIの（悪）用に関係してるみたいだね。

Electronアプリに対するデファクトの不満だってわかってるけど、メモリ使用量を除けば、主要なElectronアプリでラグの問題に遭遇したことはないな。

これまで気づかなかったけど、ネイティブアプリよりパフォーマンスが悪いのは確かだと思う。Mシリーズは今のところ余裕がありすぎて、結構なんでもいけちゃうね。