[#97652] [Ruby master Feature#16746] Endless method definition — mame@...

Issue #16746 has been reported by mame (Yusuke Endoh).

24 messages 2020/04/01

[#97655] [Ruby master Misc#16747] Repository reorganization request — shyouhei@...

Issue #16747 has been reported by shyouhei (Shyouhei Urabe).

12 messages 2020/04/01

[#97745] [Ruby master Bug#16769] Struct.new(..., immutable: true) — takashikkbn@...

Issue #16769 has been reported by k0kubun (Takashi Kokubun).

10 messages 2020/04/08

[#97803] [Ruby master Misc#16775] DevelopersMeeting20200514Japan — mame@...

Issue #16775 has been reported by mame (Yusuke Endoh).

20 messages 2020/04/10

[#97810] [Ruby master Bug#16776] Regression in coverage library — deivid.rodriguez@...

Issue #16776 has been reported by deivid (David Rodr=EDguez).

11 messages 2020/04/10

[#97828] [Ruby master Misc#16778] Should we stop vendoring default gems code? — deivid.rodriguez@...

Issue #16778 has been reported by deivid (David Rodr=EDguez).

37 messages 2020/04/11

[#97878] [Ruby master Feature#16786] Light-weight scheduler for improved concurrency. — samuel@...

Issue #16786 has been reported by ioquatix (Samuel Williams).

72 messages 2020/04/14

[#97893] [Ruby master Bug#16787] [patch] allow Dir.home to work for non-login procs when $HOME not set — salewski@...

Issue #16787 has been reported by salewski (Alan Salewski).

18 messages 2020/04/15

[#97905] [Ruby master Feature#16791] Shortcuts for attributes of Process::Status — 0xfffffff0@...

Issue #16791 has been reported by 0x81000000 (/ /).

10 messages 2020/04/16

[#97907] [Ruby master Bug#16792] Make Mutex held per Fiber instead of per Thread — eregontp@...

Issue #16792 has been reported by Eregon (Benoit Daloze).

9 messages 2020/04/16

[#97989] [Ruby master Misc#16802] Prefer use of RHS assigment in documentation — samuel@...

Issue #16802 has been reported by ioquatix (Samuel Williams).

10 messages 2020/04/21

[#97992] [Ruby master Misc#16803] Discussion: those internal macros reside in public API headers — shyouhei@...

Issue #16803 has been reported by shyouhei (Shyouhei Urabe).

14 messages 2020/04/21

[#98026] [Ruby master Bug#16809] ruby testsuite fails on s390x alpine (musl) with --with-coroutine=copy — ncopa@...

Issue #16809 has been reported by ncopa (Natanael Copa).

11 messages 2020/04/23

[#98034] [Ruby master Feature#16812] Allow slicing arrays with ArithmeticSequence — zverok.offline@...

Issue #16812 has been reported by zverok (Victor Shepelev).

12 messages 2020/04/23

[#98044] [Ruby master Bug#16814] Segmentation fault in GC while running test/ruby/test_fiber.rb on s390x — Rei.Odaira@...

Issue #16814 has been reported by ReiOdaira (Rei Odaira).

14 messages 2020/04/24

[#98059] [Ruby master Bug#16816] Prematurely terminated Enumerator should stay terminated — headius@...

Issue #16816 has been reported by headius (Charles Nutter).

9 messages 2020/04/24

[#98066] [Ruby master Feature#16818] Rename `Range#%` to `Range#/` — sawadatsuyoshi@...

Issue #16818 has been reported by sawa (Tsuyoshi Sawada).

11 messages 2020/04/26

[ruby-core:97794] [Ruby master Feature#16122] Struct::Value: simple immutable value object

From: eregontp@...
Date: 2020-04-10 12:09:43 UTC
List: ruby-core #97794
Issue #16122 has been updated by Eregon (Benoit Daloze).


We already have `Struct.new(..., keyword_init: true)`.
I think having other variants like `immutable: true, enumerable: false, hash_accessors: false` is consistent and flexible.

Having only the helpers like `Struct.Value` would restrict to a few combinations, and still need to handle `keyword_init:`.

I think `Struct::Value.new` could be a nice helper for `immutable: true, enumerable: false, hash_accessors: false`.
The others seem more specific, less common to use, and I would rather let people choose the configuration they want with keyword arguments for `Struct.new()`.

Implementation-wise and conceptually, I think it's also nicer if `Struct::Value.new(...)` is implemented as as `Struct.new(..., immutable: true, enumerable: false, hash_accessors: false)`.

----------------------------------------
Feature #16122: Struct::Value: simple immutable value object
https://bugs.ruby-lang.org/issues/16122#change-85011

* Author: zverok (Victor Shepelev)
* Status: Feedback
* Priority: Normal
----------------------------------------
**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 `#<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/

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread

Prev Next