From: "ufuk (Ufuk Kayserilioglu)" Date: 2022-09-20T21:08:24+00:00 Subject: [ruby-core:109964] [Ruby master Feature#16122] Data: simple immutable value object Issue #16122 has been updated by ufuk (Ufuk Kayserilioglu). zverok (Victor Shepelev) wrote in #note-75: > * I am not sure that "naming as a first argument" is a widely used feature, but it seems nice, so I left it for `Data` too (and tests confirming its existence); I imagine that in some systems, doing `Data.define('MyType', :members)` might be preferred way; In my opinion, this is a good time to break free from this old API and start with a better design. The fact that the `class_name` argument defines a constant under `Struct` is a little too magical, needlessly pollutes the namespace, and leads to name clashes. I would prefer it if `Data` didn't inherit the same thing from `Struct` and had a more purpose designed API from the start. I can also see from @matz 's previous message in this thread that he considers that syntax as "old-style". Moreover, the existence of the `class_name` parameter was one of his reasons against the name `Struct::Value`. It would have been horrible to not be able to use it if it was the best name for the concept, just because it could clash with someone else's magical struct class. Luckily `Data` was a better name for it. I'd rather that we don't paint ourselves into similar corners in the future. matz (Yukihiro Matsumoto) wrote in #note-45: > Struct::Value can cause conflict when someone is using `Struct.new("Value", :foo, :bar)` (this old-style code creates Struct::Value class). ---------------------------------------- Feature #16122: Data: simple immutable value object https://bugs.ruby-lang.org/issues/16122#change-99214 * Author: zverok (Victor Shepelev) * Status: Assigned * Priority: Normal * Assignee: zverok (Victor Shepelev) ---------------------------------------- **Value Object** is a useful concept, introduced by Martin Fowler ([his post](https://martinfowler.com/bliki/ValueObject.html), [Wikipedia Entry](https://en.wikipedia.org/wiki/Value_object)) with the following properties (simplifying the idea): * representing some relatively simple data; * immutable; * compared by type & value; * nicely represented. Value objects are super-useful especially for defining APIs, their input/return values. Recently, there were some movement towards using more immutability-friendly approach in Ruby programming, leading to creating several discussions/libraries with value objects. For example, [Tom Dalling's gem](https://github.com/tomdalling/value_semantics), [Good Ruby Value object convention](https://github.com/zverok/good-value-object) (disclaimer: the latter is maintained by yours truly). I propose to introduce **native value objects** to Ruby as a core class. **Why not a gem?** * I believe that concept is that simple, that nobody *will even try* to use a gem for representing it with, unless the framework/library used already provides one. * Potentially, a lot of standard library (and probably even core) APIs could benefit from the concept. **Why `Struct` is not enough** Core `Struct` class is "somewhat alike" value-object, and frequently used instead of one: it is compared by value and consists of simple attributes. On the other hand, `Struct` is: * mutable; * collection-alike (defines `to_a` and is `Enumerable`); * dictionary-alike (has `[]` and `.values` methods). The above traits somehow erodes the semantics, making code less clear, especially when duck-typing is used. For example, this code snippet shows why `to_a` is problematic: ```ruby Result = Struct.new(:success, :content) # Now, imagine that other code assumes `data` could be either Result, or [Result, Result, Result] # So, ... data = Result.new(true, 'it is awesome') Array(data) # => expected [Result(true, 'it is awesome')], got [true, 'it is awesome'] # or... def foo(arg1, arg2 = nil) p arg1, arg2 end foo(*data) # => expected [Result(true, 'it is awesome'), nil], got [true, 'it is awesome'] ``` Having `[]` and `each` defined on something that is thought as "just value" can also lead to subtle bugs, when some method checks "if the received argument is collection-alike", and value object's author doesn't thought of it as a collection. **Concrete proposal** * Class name: `Struct::Value`: lot of Rubyists are used to have `Struct` as a quick "something-like-value" drop-in, so alternative, more strict implementation, being part of `Struct` API, will be quite discoverable; *alternative: just `Value`* * Class API is copying `Struct`s one (most of the time -- even reuses the implementation), with the following exceptions *(note: the immutability is **not** the only difference)*: * Not `Enumerable`; * Immutable; * Doesn't think of itself as "almost hash" (doesn't have `to_a`, `values` and `[]` methods); * Can have empty members list (fun fact: `Struct.new('Foo')` creating member-less `Struct::Foo`, is allowed, but `Struct.new()` is not) to allow usage patterns like: ```ruby class MyService Success = Struct::Value.new(:results) NotFound = Struct::Value.new end ``` `NotFound` here, unlike, say, `Object.new.freeze` (another pattern for creating "empty typed value object"), has nice inspect `#`, and created consistently with the `Success`, making the code more readable. And if it will evolve to have some attributes, the code change would be easy. **Patch is provided** [Sample rendered RDoc documentation](https://zverok.github.io/ruby-rdoc/Struct-Value.html) ---Files-------------------------------- struct_value.patch (18.6 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: