Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It’s not. You normally can’t marshal dynamic classses or their instances across process boundaries so your multithreading options are limited. But maybe the data class has a way to do that. I see no advantage to not use concrete classes if those are good enough to get the job done.


I'm not sure what you are talking about; all classes are equally dynamic in Ruby and a class defined at the same point in the code with a factory method like Data.define and assigned to a constant can marshalled across process boundaries exactly as well as one defined with the class keyword, not as a special feature of the Data class but because using a class factory method and assogning the result to a constant is simply functionally the same thing as defining a class using the class keyword in Ruby.

The idea of distinct “concrete” and “dynamic” classes seems to be a product of a wrong mental model of how Ruby is executed.


All classes in Ruby are dynamic.

There is no effectively no difference between these:

    class Foo < Bar
      attr_accessor :baz
    end

    Foo = Class.new(Bar) do
      define_method(:baz) do
        @baz
      end
    end


Not sure I follow. The constants like Price or Currency would be available across threads.

Also, if you’re writing a custom data class, you’d need to write code to support immutability which this article’s approach handles




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: