• 恰恰相反 Ruby 只有引用类型

  • 感觉这位楼主2016年和2018年不是一个人

  • 另外我在设计这个模式的时候,研究过 Rails 4 - 5 的 ActiveModel 的演进,预判 ActiveRecord 会把更多的功能移动到 AM 中去,果不其然,最关键的显式声明字段 DSL attribute 和储存字段的 AttributeSet 都挪到了 AM 中,也就是说,Rails 6 发布后,DuckRecord 就完成历史使命了,当然我准备到时候做一套 AM 的扩展来加入嵌套模型的支持

  • ActiveType 可以,理论上可以移植到 DuckRecord,我没做这个主要俩原因,首先是懒,其次是其实我没想通这样做的场景,比如 ActiveType 文档里演示的注册表单的情况(SignUp 虚拟模型继承 User 模型),我来做的话,直接面对业务的部分我更倾向显式声明字段,这样维护性才高。

    至于命名啥的,我觉得靠命名规范可以解决,Rails 本身就是这样做的嘛。

    虚拟模型这个手法是基于 Rails 有 ActiveModel 这个公共接口,所以如果你有这方面需要可以直接用 ActiveType,不影响这套设计模式的应用

  • 其实 duck_record 支持和真实模型的关联,比如有一个真实模型 Post,建立关联可以这样

    class VirtualPost < DuckRecord::Base
      attribute :post_id, :integer
      belongs_to :post
    end
    

    应该就可以了,不过我后来反思过,虚拟模型和真实模型的关联可能会有很多边界情况,所以我在 FormCore 的例子里把所有这种写法都改写掉了,在 Presenter 层根据虚拟模型里的字段值去做查询获取真实模型的数据

    比如附件字段的 [AttachmentFieldPresenter](https://github.com/rails-engine/form_core/blob/master/test/dummy/app/presenters/fields/attachment_field_presenter.rb 这里我嫁接的 ActiveStorage

  • 因为我跟中国Py社区的组织者(们)认识啊

  • 你说 foo *[1, 2, 3]

  • 这些年的语言,都在避免 ++ --,比如 Swift、Rust,Go 虽然有,但是也有人提议在 Go 2 删掉,用 var += 1 写法代替,当然不同意的人也有很多

  • 如果禁用 AP 并且不用 Webpacker 或者其他关联前端工具链的方案的话,你就只能把编译好前端资源放到 public 目录下了,这个就是Rails 3.1前的做法,目前 Redmine 这些上古项目也还是这么用(貌似)

非 geek、非 hacker、二流工程师