Ruby 開發社群正在就程式碼安全性和靈活性之間的權衡展開激烈討論，這場討論由允許開發者凍結 Ruby 核心類的 Refrigerator 元件引發。這凸顯了 Ruby 生態系統中在保持語言著名的靈活性和防止潛在危險的執行時修改之間的根本性矛盾。
Core Class Freezing 的主要特點：
- 防止在執行時修改 Ruby 核心類
- 當嘗試修改已凍結的類時會引發 FrozenError
- 允許將特定類排除在凍結範圍之外
- 提供用於檢查庫相容性的測試工具
安全性與靈活性
防止核心類修改的工具的引入引發了關於 Ruby 程式設計正規化的重要討論。一些開發者歡迎防止執行時修改所帶來的額外安全性，而另一些人則認為這種方法違背了 Ruby 的基本設計原則。爭論的焦點在於是否值得為修改核心類的能力（Ruby 的著名特性之一）承擔其帶來的潛在風險。
「Ruby 的設計本就允許擴充套件核心類—— Rails 在各處都在這樣做。如果我把一個 require 放在功能標誌後面，當它失敗時可能會讓我感到意外。」
效能影響
開發者們對凍結核心類的效能影響提出了重要疑問。雖然凍結操作本身主要涉及在物件元資料中設定標誌，但在執行時檢查這些標誌的開銷仍然令人擔憂。社群注意到，深度凍結大型物件樹可能會帶來明顯的效能損失，特別是在處理大量資料結構的應用程式中。
實際應用和侷限性
討論揭示了雖然類凍結在測試和開發環境中可能有益，但在生產環境中的使用仍然存在爭議。許多開發者分享了維護遺留程式碼庫的經歷，其中不受限制的核心類修改導致了除錯噩夢。然而，該工具與 Rails 等流行框架的相容性仍然是一個重要問題，因為這些框架嚴重依賴核心類擴充套件。
常見使用場景：
- 測試環境
- 開發除錯
- 安全敏感應用
- 遺留程式碼庫分析
現代替代方案
社群強調了在 Ruby 中處理不可變性的更現代方法，例如 Ruby 3.2 中引入的 Data 類以及用於範圍限定修改的 Refinements 。這些替代方案在保持 Ruby 靈活特性的同時，提供了對程式碼修改更細粒度的控制。
總之，雖然像 Refrigerator 這樣的工具為 Ruby 開發提供了重要的安全機制，但在採用時需要仔細考慮具體用例和對現有程式碼庫的潛在影響。這場討論凸顯了 Ruby 開發實踐的持續演進，以及社群在靈活性和可維護性之間尋求平衡的努力。