From: "matz (Yukihiro Matsumoto)" <noreply@ruby-lang.org>
To: ruby-core@ruby-lang.org
Subject: [ruby-core:110084] [Ruby master Feature#16122] Data: simple immutable value object
Date: Mon, 26 Sep 2022 09:58:22 +0000 (UTC) [thread overview]
Message-ID: <redmine.journal-99339.20220926095822.710@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-16122.20190823174036.710@ruby-lang.org
Issue #16122 has been updated by matz (Yukihiro Matsumoto).
@zverok The summary looks OK. I accepted.
@ioquatix Your proposal should be handled separately. Could you submit a new one?
Matz.
----------------------------------------
Feature #16122: Data: simple immutable value object
https://bugs.ruby-lang.org/issues/16122#change-99339
* Author: zverok (Victor Shepelev)
* Status: Assigned
* Priority: Normal
* Assignee: zverok (Victor Shepelev)
----------------------------------------
## Intro (original theoretical part of the proposal)
**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.
## `Data` class: consensus proposal/implementation, Sep 2022
* Name: `Data`
* PR: https://github.com/ruby/ruby/pull/6353
* Example docs rendering: https://zverok.space/ruby-rdoc/Data.html
* Full API:
* `Data::define` creates a new Data class; accepts only symbols (no `keyword_init:`, no "first argument is the class name" like the `Struct` had)
* `<data_class>::members`: list of member names
* `<data_class>::new`: accepts either keyword or positional arguments (but not mix); converts all of the to keyword args; raises `ArgumentError` if there are **too many positional arguments**
* `#initialize`: accepts only keyword arguments; the default implementation raises `ArgumentError` on missing or extra arguments; it is easy to redefine `initialize` to provide defaults or handle extra args.
* `#==`
* `#eql?`
* `#inspect`/`#to_s` (same representation)
* `#deconstruct`
* `#deconstruct_keys`
* `#hash`
* `#members`
* `#to_h`
## Historical original 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 `#<value NotFound>`, 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/
next prev parent reply other threads:[~2022-09-26 9:58 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <redmine.issue-16122.20190823174036.710@ruby-lang.org>
2020-04-10 12:09 ` [ruby-core:97794] [Ruby master Feature#16122] Struct::Value: simple immutable value object eregontp
2020-04-10 12:13 ` [ruby-core:97795] " eregontp
2022-01-11 7:29 ` [ruby-core:107040] " ko1 (Koichi Sasada)
2022-01-11 7:43 ` [ruby-core:107041] " zverok (Victor Shepelev)
2022-01-11 7:47 ` [ruby-core:107043] " ko1 (Koichi Sasada)
2022-01-11 7:52 ` [ruby-core:107044] " zverok (Victor Shepelev)
2022-01-11 16:16 ` [ruby-core:107054] " Dan0042 (Daniel DeLorme)
2022-01-29 8:31 ` [ruby-core:107344] " mame (Yusuke Endoh)
2022-01-30 12:53 ` [ruby-core:107364] " Eregon (Benoit Daloze)
2022-01-30 20:39 ` [ruby-core:107366] " matheusrich (Matheus Richard)
2022-01-30 20:57 ` [ruby-core:107367] " Dan0042 (Daniel DeLorme)
2022-01-30 21:49 ` [ruby-core:107369] " myronmarston (Myron Marston)
2022-02-12 21:54 ` [ruby-core:107566] " dsisnero (Dominic Sisneros)
2022-08-16 15:18 ` [ruby-core:109500] " mame (Yusuke Endoh)
2022-08-16 15:31 ` [ruby-core:109502] " mame (Yusuke Endoh)
2022-08-16 15:54 ` [ruby-core:109503] " Eregon (Benoit Daloze)
2022-08-18 6:38 ` [ruby-core:109527] " k0kubun (Takashi Kokubun)
2022-08-18 6:59 ` [ruby-core:109530] " baweaver (Brandon Weaver)
2022-08-18 14:14 ` [ruby-core:109549] " zverok (Victor Shepelev)
2022-08-18 17:05 ` [ruby-core:109552] " myronmarston (Myron Marston)
2022-08-18 17:59 ` [ruby-core:109556] " k0kubun (Takashi Kokubun)
2022-08-19 8:23 ` [ruby-core:109567] " mame (Yusuke Endoh)
2022-08-19 8:30 ` [ruby-core:109568] " mame (Yusuke Endoh)
2022-08-19 10:13 ` [ruby-core:109570] " zverok (Victor Shepelev)
2022-08-19 10:19 ` [ruby-core:109571] " matz (Yukihiro Matsumoto)
2022-08-19 16:24 ` [ruby-core:109577] " zverok (Victor Shepelev)
2022-08-19 19:09 ` [ruby-core:109579] " k0kubun (Takashi Kokubun)
2022-08-20 10:31 ` [ruby-core:109587] " Eregon (Benoit Daloze)
2022-08-25 10:40 ` [ruby-core:109684] " matz (Yukihiro Matsumoto)
2022-08-25 11:25 ` [ruby-core:109685] " zverok (Victor Shepelev)
2022-08-25 13:34 ` [ruby-core:109691] " matz (Yukihiro Matsumoto)
2022-08-25 20:02 ` [ruby-core:109697] [Ruby master Feature#16122] Data: " k0kubun (Takashi Kokubun)
2022-08-25 22:48 ` [ruby-core:109699] " k0kubun (Takashi Kokubun)
2022-08-26 10:22 ` [ruby-core:109706] " Eregon (Benoit Daloze)
2022-08-26 16:53 ` [ruby-core:109715] " austin (Austin Ziegler)
2022-08-26 19:08 ` [ruby-core:109718] " Eregon (Benoit Daloze)
2022-08-27 16:34 ` [ruby-core:109742] " zverok (Victor Shepelev)
2022-09-01 15:58 ` [ruby-core:109814] " RubyBugs (A Nonymous)
2022-09-01 16:00 ` [ruby-core:109815] " RubyBugs (A Nonymous)
2022-09-01 16:04 ` [ruby-core:109816] " RubyBugs (A Nonymous)
2022-09-01 16:09 ` [ruby-core:109817] " RubyBugs (A Nonymous)
2022-09-03 8:41 ` [ruby-core:109830] " k0kubun (Takashi Kokubun)
2022-09-08 18:20 ` [ruby-core:109851] " RubyBugs (A Nonymous)
2022-09-08 19:50 ` [ruby-core:109857] " RubyBugs (A Nonymous)
2022-09-09 21:26 ` [ruby-core:109864] " shugo (Shugo Maeda)
2022-09-09 23:06 ` [ruby-core:109866] " k0kubun (Takashi Kokubun)
2022-09-10 11:08 ` [ruby-core:109870] " Eregon (Benoit Daloze)
2022-09-10 12:35 ` [ruby-core:109872] " zverok (Victor Shepelev)
2022-09-10 13:46 ` [ruby-core:109874] " Eregon (Benoit Daloze)
2022-09-10 13:55 ` [ruby-core:109875] " zverok (Victor Shepelev)
2022-09-10 14:04 ` [ruby-core:109876] " Eregon (Benoit Daloze)
2022-09-10 14:12 ` [ruby-core:109877] " zverok (Victor Shepelev)
2022-09-10 16:41 ` [ruby-core:109878] " Eregon (Benoit Daloze)
2022-09-11 2:54 ` [ruby-core:109883] " nobu (Nobuyoshi Nakada)
2022-09-20 18:16 ` [ruby-core:109963] " zverok (Victor Shepelev)
2022-09-20 21:08 ` [ruby-core:109964] " ufuk (Ufuk Kayserilioglu)
2022-09-22 3:30 ` [ruby-core:109986] " nobu (Nobuyoshi Nakada)
2022-09-22 18:50 ` [ruby-core:109999] " zverok (Victor Shepelev)
2022-09-22 22:45 ` [ruby-core:110012] " nobu (Nobuyoshi Nakada)
2022-09-22 22:57 ` [ruby-core:110013] " zverok (Victor Shepelev)
2022-09-23 0:44 ` [ruby-core:110020] " matz (Yukihiro Matsumoto)
2022-09-25 11:43 ` [ruby-core:110068] " zverok (Victor Shepelev)
2022-09-26 0:39 ` [ruby-core:110072] " ioquatix (Samuel Williams)
2022-09-26 9:58 ` matz (Yukihiro Matsumoto) [this message]
2022-09-26 12:15 ` [ruby-core:110086] " nobu (Nobuyoshi Nakada)
2022-09-27 18:32 ` [ruby-core:110113] " zverok (Victor Shepelev)
2022-12-03 16:24 ` [ruby-core:111179] " ston1x (Nicolai Stoianov)
2022-12-05 7:22 ` [ruby-core:111206] " matz (Yukihiro Matsumoto)
2022-12-05 18:43 ` [ruby-core:111213] " zverok (Victor Shepelev)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-99339.20220926095822.710@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).