Rails框架RoR并不是用Ruby编写的

22-02-05 banq

这是来自波兰人solnic.codes的帖子,大意如下:
波兰语是一门非常难学的语言,它实际上被认为是世界上最难学习的 10 种语言之一。在波兰,就像在许多其他国家一样,有些地区使用方言而不是“纯粹”的语言形式,所以在我的城市,我们有自己的方言。
编程语言也有方言,根据定义,编程语言方言是“语言的(相对较小的)变体或扩展,不会改变其内在性质”。这种变化或扩展是如何实现的并不重要。重要的部分是原始语言得到了扩展,它提供了更多的功能,而它的原始性质和行为保持不变。
Ruby是一种具有开放类的编程语言,即使是语言的核心功能也可以通过简单地向核心类添加新方法来扩展,例如String或Array. 这使得创建自己的 Ruby 方言变得非常简单!
DHH 在创建 Ruby on Rails 框架时就利用了 Ruby 的这一独特功能。这个框架的基础是一个名为 ActiveSupport 的库——一个核心 Ruby 扩展的大集合,它们共同创建了一个 Ruby 方言,一个 Ruby 语言的扩展版本,它不会改变它的内在本质。

如果你试图从 Rails 中删除 ActiveSupport,一切都会崩溃。
 

Monkey-patching是另一种说法,即某段代码通过利用Ruby中的开放类来改变一个现有的类。ActiveSupport库对许多类进行了Monkey-patch,目前在其core_ext目录下有3471个LOC。
当你有一个库,一个 ruby​​ gem,它为核心类添加了如此大量的新方法时,理解这一点很重要:

  • 您不再使用 Ruby,您现在使用的是 Ruby 方言,实现为名为 ActiveSupport 的库
  • 您必须知道,您在应用程序代码中添加到自己的类的方法可能会导致与 ActiveSupport 发生冲突
  • 构建其他库(也是猴子补丁核心类)是一个非常糟糕的主意,因为它们也会导致冲突

前段时间,我们有很大依赖monkey-patching的ruby gems,我们甚至有一个旨在与 Rails 竞争的全栈框架。它被称为 Merb,它也有类似 ActiveSupport 的东西,它被称为 extlib。正如您可能猜到的那样——它导致了与 ActiveSupport 的冲突,因此在同一个代码库中使用这两个库并不可行。
不过,Merb 和 Rails “合并”到了 Rails 3 中,这就是我们不再有“extlib 问题”的原因,因为库已经消失了。
随着时间的推移,许多从事各种 gem 的 Ruby 开发人员已经了解了monkey-patching的缺点,并且干脆停止了。
不幸的是,即使大多数 gem 不再依赖于monkey-patchin,我们仍然有 ActiveSupport,因为它是 Rails 的基础部分。毕竟,框架是用 ActiveSupport Ruby 方言编写的!
不过,问题的症结在于:

作为 Ruby 方言的一部分实现的 API 看起来“更好”、更简洁和自然

为什么?因为它看起来像是语言的一部分!这就是为什么像这样的东西1.day.ago看起来如此“自然”。除了它不是 Ruby ,因为它是 ActiveSupport。
 
更多点击标题
 

1
猜你喜欢