December 2022 - ruby-core - ml.ruby-lang.org

[ruby-core:111172] [Ruby master Misc#19176] How to find insns_info for iseq in ruby 3.2
by hurricup (Alexandr Evstigneev) 04 Dec '22

04 Dec '22

Issue #19176 has been reported by hurricup (Alexandr Evstigneev). ---------------------------------------- Misc #19176: How to find insns_info for iseq in ruby 3.2 https://bugs.ruby-lang.org/issues/19176 * Author: hurricup (Alexandr Evstigneev) * Status: Open * Priority: Normal ---------------------------------------- I'm not quite sure it is a proper place to ask questions, correct me if I'm wrong. But I have a problem with ruby-3.2.0 previews. Looks like iseq is missing `insns_info`s. It works fine in with pre-3.2 rubies but seems something has changed and I can't figure out - what exactly. It looks like this: ![](clipboard-202212031723-don1h.png) You may see that body, supposed to be a pointer to `iseq_insn_info_entry` contains some 0x7 pointing nowhere. And `size` for `insns_info` in all `iseq` I can find with iterating objspace is zero. ---Files-------------------------------- clipboard-202212031723-don1h.png (375 KB) -- https://bugs.ruby-lang.org/

1 1

[ruby-core:111197] [Ruby master Feature#17942] Add a `initialize(public @a, private @b)` shortcut syntax for defining public/private accessors for instance vars as part of constructor
by sawa (Tsuyoshi Sawada) 04 Dec '22

04 Dec '22

Issue #17942 has been updated by sawa (Tsuyoshi Sawada). LevLukomskyi (Lev Lukomskyi) wrote in #note-6: > [Y]ou are forced to create a lot of duplication [...] > > class PollItem::ToggleVote > attr_reader :poll_item, :user, :voted, :ip_address > > def initialize(poll_item, user, voted, ip_address:) > @poll_item = poll_item > @user = user > @voted = voted > @ip_address = ip_address > end > Here we see `poll_item`, `user`, `voted`, `ip_address` names are duplicated 4 times Not necessarily. You can do with 2 times (counting the use with `attr_reader`): def initialize(*args) @poll_item, @user, @voted, @ip_address = args end > I saw **Matz was against this feature**, the main point was: > > > def initialize(@foo, @bar) > > end > > does not express intention of instance variable initialization > > But – **it does express** – there is a word `initialize` and then goes `@foo`, it means "Please initialize @foo with whatever is passed here". No, it doesn't. It means "please initialize **the newly created instance** with whatever is passed here as the value of `@foo`." In general, Ruby code `foo.bar(baz)` translates to English as "do bar to foo using baz", not "foo does bar to baz." ---------------------------------------- Feature #17942: Add a `initialize(public @a, private @b)` shortcut syntax for defining public/private accessors for instance vars as part of constructor https://bugs.ruby-lang.org/issues/17942#change-100480 * Author: TylerRick (Tyler Rick) * Status: Open * Priority: Normal ---------------------------------------- This proposal builds on the proposed `initialize(@a, @b)` instance var assignment shortcut syntax described in #15192. 1. It allows you to add an *optional* `public`/`protected`/`private` modifier before any instance var parameter. Doing so automatically defines *accessor methods* (with the given access modifier; equivalent to `attr_accessor` inside of a `public`/`protected`/`private` block) for the instance var it precedes. 2. If the visibility modifier is omitted, then it defaults to automatically _no_ getter/setter methods for that instance var (it _only_ does an assignment of that already-private instance var). ## Parameter properties in TypeScript language This is inspired by TypeScript's `constructor(public a, private b)` syntax, which allows you to write this ([REPL](https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8BQ0PWPAdh…) ```js class Foo { constructor(public a:number, public b:number, private c:number) { } } ``` instead of this: ```js class Foo { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } } ``` (The `public`/`private` access modifiers actually disappear in the transpiled JavaScript code because it's only the TypeScript compiler that enforces those access modifiers, and it does so at *compile* time rather than at run time.) Further reading: - https://www.typescriptlang.org/docs/handbook/2/classes.html#parameter-prope… - https://basarat.gitbook.io/typescript/future-javascript/classes#define-usin… - https://kendaleiv.com/typescript-constructor-assignment-public-and-private-… ## Differences from TypeScript I propose adding a similar feature to Ruby, but with following differences from TypeScript: 1. Use **`@a`** instead of bare `a`. This makes it *much* clearer that you are assigning directly to instance variables instead of to locals. - Rationale: The `@` is actually _part_ of the instance variable name, and is inseparable from it. (This is also consistent with how the `#` is part of the name itself in JavaScript's [(Private instance fields)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/….) - (`public a` would be a syntax error because there's no such thing as access modifiers for locals. Okay, I guess there's no such thing as access modifiers for instance vars either, which is why...) 1. Make the syntax for ***assigning*** to instance vars (`@a`) (the proposal in #15192) and defining ***accessor methods*** for those instance vars (`public`/`private`) separate/distinct. - In other words, rather than make the `public`/`private` keywords a *required* part of the syntax like it is for TypeScript [parameter properties](https://www.typescriptlang.org/docs/handbook/2/classes.html#par…, you could omit the modifier and it would still do the instance var _assignment*. - The `public`/`private` access modifiers be an additional (*optional*) shortcut when you want to add an ***accessor method*** in *addition* to doing an ***assignment*** . - Unlike Java and TypeScript where you _can_ add access modifiers to instance variables, in Ruby, `public`/`private` _can't_ be applied to instance variables (direct access is only possible from within the instance). So if we're going to allow a `public`/`private` modifier here at all, They _must_ refer to methods, specifically accessor methods for those instance variables. 1. Keep it **private** by default (which of course `@a` by itself implies—it _is_ private unless you add a public accessor). - (Rather than make it `public` by default like it is in TypeScript.) - Keeping instance variables completely private is probably what people will want most of the time, and we should optimize the ergonomics for the most common case. - Private is a safer default, and should be assumed unless you explicitly ask for a public accessor to be added. - I bet TypeScript made the `public` the default mostly to be consistent with JavaScript (which TypeScript compiles to): JavaScript (along with other languages like Java) allows direct access (no getter/setter neede) to instance properties/variables from objects outside the instance. JavaScript doesn't even _have_ a way to make instance variables private (but hopefully will soon with this [proposal](https://github.com/tc39/proposal-private-methods) to add `#a` syntax for private properties). So this: ```ruby class Thing def initialize(public @a, public @b, @c) end end ``` would be equivalent to this: ```ruby class Thing attr_accessor :a, :b def initialize(a, b, c) @a = a @b = b @c = c end ``` ## How is `initialize(private @a)` different from `initialize(@a)`? Even though `@a` by itself is already private... 1. This defines a private accessor for that instance var, which lets you write `self.a =` instead of `@a =` (if you want). 2. Having a concise way to do that is helpful, for example if you want to make it a matter of practice/policy to only set an instance variable by going through its *setter method*. (See [discussion here](https://stackoverflow.com/questions/25571642/ruby-private-and-public-….) Why not just use `initialize(private @a)` to be consistent with TypeScript spec? - TypeScript's `public`/`private` is not standard JavaScript. In fact, if the [private methods/fields proposal](https://github.com/tc39/proposal-private-methods) had existed when TypeScript added [parameter properties](https://www.typescriptlang.org/docs/handbook/2/classes.html#par…, I'd like to think that they might have actually *made use* of the new `#b` syntax and gone with a terser syntax like `constructor(public a, #b)` instead of ``constructor(public a, private b)`. ## Upsides of this proposal 1. Removes even more boilerplate (all those `attr_accessor` lines), much of the time ## Downsides of this proposal 1. Only provides a way to define both getter and setter at once. Doesn't provide a way to _just_ define a getter and not a setter, for example. - Doesn't seem like a big deal, however. You can just not use this feature and define the getter with `attr_reader :a` instead. Or define private getter/setter with `private @a` and then override with `attr_reader :a` to add a public getter (while keeping the private setter). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111196] [Ruby master Feature#17942] Add a `initialize(public @a, private @b)` shortcut syntax for defining public/private accessors for instance vars as part of constructor
by nobu (Nobuyoshi Nakada) 04 Dec '22

04 Dec '22

Issue #17942 has been updated by nobu (Nobuyoshi Nakada). This means you want only `initialize` method to be parsed specially? And when bypassing this method, e.g., `Marshal.load`, no accessor will be defined? ---------------------------------------- Feature #17942: Add a `initialize(public @a, private @b)` shortcut syntax for defining public/private accessors for instance vars as part of constructor https://bugs.ruby-lang.org/issues/17942#change-100479 * Author: TylerRick (Tyler Rick) * Status: Open * Priority: Normal ---------------------------------------- This proposal builds on the proposed `initialize(@a, @b)` instance var assignment shortcut syntax described in #15192. 1. It allows you to add an *optional* `public`/`protected`/`private` modifier before any instance var parameter. Doing so automatically defines *accessor methods* (with the given access modifier; equivalent to `attr_accessor` inside of a `public`/`protected`/`private` block) for the instance var it precedes. 2. If the visibility modifier is omitted, then it defaults to automatically _no_ getter/setter methods for that instance var (it _only_ does an assignment of that already-private instance var). ## Parameter properties in TypeScript language This is inspired by TypeScript's `constructor(public a, private b)` syntax, which allows you to write this ([REPL](https://www.typescriptlang.org/play?#code/MYGwhgzhAEBiD29oG8BQ0PWPAdh…) ```js class Foo { constructor(public a:number, public b:number, private c:number) { } } ``` instead of this: ```js class Foo { constructor(a, b, c) { this.a = a; this.b = b; this.c = c; } } ``` (The `public`/`private` access modifiers actually disappear in the transpiled JavaScript code because it's only the TypeScript compiler that enforces those access modifiers, and it does so at *compile* time rather than at run time.) Further reading: - https://www.typescriptlang.org/docs/handbook/2/classes.html#parameter-prope… - https://basarat.gitbook.io/typescript/future-javascript/classes#define-usin… - https://kendaleiv.com/typescript-constructor-assignment-public-and-private-… ## Differences from TypeScript I propose adding a similar feature to Ruby, but with following differences from TypeScript: 1. Use **`@a`** instead of bare `a`. This makes it *much* clearer that you are assigning directly to instance variables instead of to locals. - Rationale: The `@` is actually _part_ of the instance variable name, and is inseparable from it. (This is also consistent with how the `#` is part of the name itself in JavaScript's [(Private instance fields)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/….) - (`public a` would be a syntax error because there's no such thing as access modifiers for locals. Okay, I guess there's no such thing as access modifiers for instance vars either, which is why...) 1. Make the syntax for ***assigning*** to instance vars (`@a`) (the proposal in #15192) and defining ***accessor methods*** for those instance vars (`public`/`private`) separate/distinct. - In other words, rather than make the `public`/`private` keywords a *required* part of the syntax like it is for TypeScript [parameter properties](https://www.typescriptlang.org/docs/handbook/2/classes.html#par…, you could omit the modifier and it would still do the instance var _assignment*. - The `public`/`private` access modifiers be an additional (*optional*) shortcut when you want to add an ***accessor method*** in *addition* to doing an ***assignment*** . - Unlike Java and TypeScript where you _can_ add access modifiers to instance variables, in Ruby, `public`/`private` _can't_ be applied to instance variables (direct access is only possible from within the instance). So if we're going to allow a `public`/`private` modifier here at all, They _must_ refer to methods, specifically accessor methods for those instance variables. 1. Keep it **private** by default (which of course `@a` by itself implies—it _is_ private unless you add a public accessor). - (Rather than make it `public` by default like it is in TypeScript.) - Keeping instance variables completely private is probably what people will want most of the time, and we should optimize the ergonomics for the most common case. - Private is a safer default, and should be assumed unless you explicitly ask for a public accessor to be added. - I bet TypeScript made the `public` the default mostly to be consistent with JavaScript (which TypeScript compiles to): JavaScript (along with other languages like Java) allows direct access (no getter/setter neede) to instance properties/variables from objects outside the instance. JavaScript doesn't even _have_ a way to make instance variables private (but hopefully will soon with this [proposal](https://github.com/tc39/proposal-private-methods) to add `#a` syntax for private properties). So this: ```ruby class Thing def initialize(public @a, public @b, @c) end end ``` would be equivalent to this: ```ruby class Thing attr_accessor :a, :b def initialize(a, b, c) @a = a @b = b @c = c end ``` ## How is `initialize(private @a)` different from `initialize(@a)`? Even though `@a` by itself is already private... 1. This defines a private accessor for that instance var, which lets you write `self.a =` instead of `@a =` (if you want). 2. Having a concise way to do that is helpful, for example if you want to make it a matter of practice/policy to only set an instance variable by going through its *setter method*. (See [discussion here](https://stackoverflow.com/questions/25571642/ruby-private-and-public-….) Why not just use `initialize(private @a)` to be consistent with TypeScript spec? - TypeScript's `public`/`private` is not standard JavaScript. In fact, if the [private methods/fields proposal](https://github.com/tc39/proposal-private-methods) had existed when TypeScript added [parameter properties](https://www.typescriptlang.org/docs/handbook/2/classes.html#par…, I'd like to think that they might have actually *made use* of the new `#b` syntax and gone with a terser syntax like `constructor(public a, #b)` instead of ``constructor(public a, private b)`. ## Upsides of this proposal 1. Removes even more boilerplate (all those `attr_accessor` lines), much of the time ## Downsides of this proposal 1. Only provides a way to define both getter and setter at once. Doesn't provide a way to _just_ define a getter and not a setter, for example. - Doesn't seem like a big deal, however. You can just not use this feature and define the getter with `attr_reader :a` instead. Or define private getter/setter with `private @a` and then override with `attr_reader :a` to add a public getter (while keeping the private setter). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111195] [Ruby master Bug#19144] Ruby should set AI_V4MAPPED | AI_ADDRCONFIG getaddrinfo flags by default
by kjtsanaktsidis (KJ Tsanaktsidis) 04 Dec '22

04 Dec '22

Issue #19144 has been updated by kjtsanaktsidis (KJ Tsanaktsidis). A gentle poke to see if anybody has some thoughts on this? ---------------------------------------- Bug #19144: Ruby should set AI_V4MAPPED | AI_ADDRCONFIG getaddrinfo flags by default https://bugs.ruby-lang.org/issues/19144#change-100478 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Currently, DNS lookups made with `getaddrinfo` from Ruby (i.e. not from the `Resolv` module) cause both A and AAAA DNS requests to be made, even on systems that don’t actually have an IPv6 address that could possibly make the AAAA response useful. I wouldn’t _really_ care about this, normally, but glibc has a bug (https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1961697) which can cause a 5-second delay in DNS lookups when both A and AAAA records are queried in parallel. This bug is fixed in glibc upstream but still present in some LTS linux distros (Ubuntu 18.04 and 20.04 at least), so I think it’s worthwhile to try and work around it in circumstances where the AAAA request is pointless anyway. The dual A/AAAA lookup happens because whenever Ruby calls getaddrinfo to perform DNS lookups, it always sets `hints`, and sets `hints->ai_flags` to zero by default unless flags are specified by the caller (e.g. `AI_PASSIVE` is set when binding a TCP server socket in `TCPServer.new`). This matches the default value of `ai_flags` specified by POSIX, which is zero. However, glibc behaves differently. When glibc’s `getaddrinfo` function is called with `NULL` for the `hints` parameter, it defaults the `ai_flags` value to `(AI_V4MAPPED | AI_ADDRCONFIG)`. The manpage (from the Linux man-pages project - https://man7.org/linux/man-pages/man3/getaddrinfo.3.html) claims “this is an improvement on the standard” (although I couldn’t find this mentioned in the glibc manual itself). Of course, we’re not _actually_ ever calling `getaddrinfo` with NULL `hints`; so, we never actually use these flags on glibc systems (unless they’re explicitly specified by the caller). My proposal is that we should change Ruby to set these two flags by default, when they’re available, in the following circumstances: * In all calls made internally to `rsock_getaddrinfo` as a result of socket functions like `TCPSocket.new`, `UDPSocket.new`, etc. * EXCEPT when `AI_PASSIVE` is also set (i.e. when we’re trying to get an address to bind for listener socket - see below) * In calls made to `rsock_getaddrinfo` as a direct result of calling `Addrinfo.getaddrinfo` from Ruby with nil flags * EXCEPT calls to `Addrinfo.getaddrinfo` where explicit flags are provided Both of these seem like something you would almost always want to be doing in any outgoing connection scenario: * `AI_V4MAPPED` ensures that, if AF_INET6 is explicitly specified as the desired protocol, and there is no AAAA record in DNS, that any A record that _is_ present gets converted to an IPv4-mapped IPv6 address so it can be used e.g. with NAT64. * `AI_ADDRCONFIG` ensures that, if a machine has no IPv6 address, it doesn’t bother making an AAAA lookup that will return IPv6 addresses that can’t actually be used for anything (and vice versa for IPv4). The reason why we wouldn’t want to set `AI_ADDRCONFIG` in circumstances where Ruby currently sets `AI_PASSIVE` is that loopback addresses are not considered in deciding if a system has an IPv4/IPv6 address. Conceivably, you might want to bind to a `::1` loopback address, and allow other processes on the same machine to connect to that. Does changing this default sound reasonable? If so I can prepare a patch. Another option I considered is doing this _only_ when Ruby is built against glibc (so that other system behaviour is most closely matched). -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111143] [Ruby master Misc#19170] DevMeeting-2022-12-15
by mame (Yusuke Endoh) 03 Dec '22

03 Dec '22

Issue #19170 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #19170: DevMeeting-2022-12-15 https://bugs.ruby-lang.org/issues/19170 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- # The next dev meeting **Date: 2022/12/15 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2022/12/12. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:111180] [Ruby master Feature#19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object]
by RubyBugs (A Nonymous) 03 Dec '22

03 Dec '22

Issue #19000 has been updated by RubyBugs (A Nonymous). > …treats unknown keywords passed to this method as an error. I had already made it clear that I thought it should be an error at the end of my message earlier in this thread … and I think we are all in agreement on this point in this thread. **+1** agreement on treating unknown keywords as error! :-) ---------------------------------------- Feature #19000: Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] https://bugs.ruby-lang.org/issues/19000#change-100464 * Author: RubyBugs (A Nonymous) * Status: Open * Priority: Normal ---------------------------------------- *As requested: extracted a follow-up to #16122 Data: simple immutable value object from [this comment](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/109815)* # Proposal: Add a "Copy with changes" method to Data Assume the proposed `Data.define` exists. Seeing examples from the [[Values gem]](https://github.com/ms-ati/Values): ```ruby require "values" # A new class Point = Value.new(:x, :y) # An immutable instance Origin = Point.with(x: 0, y: 0) # Q: How do we make copies that change 1 or more values? right = Origin.with(x: 1.0) up = Origin.with(y: 1.0) up_and_right = right.with(y: up.y) # In loops movements = [ [ :x, +0.5 ], [ :x, +0.5 ], [ :y, -1.0 ], [ :x, +0.5 ], ] # position = Point(x: 1.5, y: -1.0) position = movements.inject(Origin) do |p, (field, delta)| p.with(field => p.send(field) + delta) end ``` ## Proposed detail: Call this method: `#with` ```ruby Money = Data.define(:amount, :currency) account = Money.new(amount: 100, currency: 'USD') transactions = [+10, -5, +15] account = transactions.inject(account) { |a, t| a.with(amount: a.amount + t) } #=> Money(amount: 120, currency: "USD") ``` ## Why add this "Copy with changes" method to the Data simple immutable value class? Called on an instance, it returns a new instance with only the provided parameters changed. This API affordance is now **widely adopted across many languages** for its usefulness. Why is it so useful? Because copying immutable value object instances, with 1 or more discrete changes to specific fields, is the proper and ubiquitous pattern that takes the place of mutation when working with immutable value objects. **Other languages** C# Records: “immutable record structs — Non-destructive mutation” — is called `with { ... }` https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-t… Scala Case Classes — is called `#copy` https://docs.scala-lang.org/tour/case-classes.html Java 14+ Records — Brian Goetz at Oracle is working on adding a with copy constructor inspired by C# above as we speak, likely to be called `#with` https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html Rust “Struct Update Syntax” via `..` syntax in constructor https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-insta… ## Alternatives Without a copy-with-changes method, one must construct entirely new instances using the constructor. This can either be (a) fully spelled out as boilerplate code, or (b) use a symmetrical `#to_h` to feed the keyword-args constructor. **(a) Boilerplate using constructor** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(x: Origin.x, y: Origin.y, **change) ``` **(b) Using a separately proposed `#to_h` method and constructor symmetry** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(**(Origin.to_h.merge(change))) ``` Notice that the above are not ergonomic -- leading so many of our peer language communities to adopt the `#with` method to copy an instance with discrete changes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111179] [Ruby master Feature#16122] Data: simple immutable value object
by ston1x (Nicolai Stoianov) 03 Dec '22

03 Dec '22

Issue #16122 has been updated by ston1x (Nicolai Stoianov). Thanks a lot for implementing this feature! Can't wait to start applying it in specific use-cases. However, I am also wondering if it is possible to define such `Data`-derived classes in a "traditional way", meaning something like: ```ruby class Ticket < Data # "attrs" is just for example here, might be something different. attrs :event_id, :user_id, :start_at # And other methods defined below def validate puts "Validated!" end end # And then just using it the same way as described in the PR: ticket = Ticket.new( event_id: 78, user_id: 584, start_at: '2022-12-03 15:00:00' ) ``` I guess this might come in handy for IDEs and is simply common across codebases in Ruby. Please correct me if I'm wrong or if you've also considered similar assumptions but decided to not implement it on purpose. ---------------------------------------- Feature #16122: Data: simple immutable value object https://bugs.ruby-lang.org/issues/16122#change-100463 * Author: zverok (Victor Shepelev) * Status: Closed * 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/

1 0

[ruby-core:111178] [Ruby master Feature#19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object]
by ufuk (Ufuk Kayserilioglu) 03 Dec '22

03 Dec '22

Issue #19000 has been updated by ufuk (Ufuk Kayserilioglu). austin (Austin Ziegler) wrote in #note-32: > If `origin` is a `Point` containing `x` and `y` values, then `origin#copy(x: 1, y: 2, z: 3)` should do…what? Should it error or just take the values that it knows? The [current implementation in the PR](https://github.com/ruby/ruby/pull/6766) treats unknown keywords passed to this method as an error. I had already made it clear that I thought it should be an error at the end of my message earlier in this thread https://bugs.ruby-lang.org/issues/19000#note-7 and I think we are all in agreement on this point in this thread. ---------------------------------------- Feature #19000: Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] https://bugs.ruby-lang.org/issues/19000#change-100462 * Author: RubyBugs (A Nonymous) * Status: Open * Priority: Normal ---------------------------------------- *As requested: extracted a follow-up to #16122 Data: simple immutable value object from [this comment](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/109815)* # Proposal: Add a "Copy with changes" method to Data Assume the proposed `Data.define` exists. Seeing examples from the [[Values gem]](https://github.com/ms-ati/Values): ```ruby require "values" # A new class Point = Value.new(:x, :y) # An immutable instance Origin = Point.with(x: 0, y: 0) # Q: How do we make copies that change 1 or more values? right = Origin.with(x: 1.0) up = Origin.with(y: 1.0) up_and_right = right.with(y: up.y) # In loops movements = [ [ :x, +0.5 ], [ :x, +0.5 ], [ :y, -1.0 ], [ :x, +0.5 ], ] # position = Point(x: 1.5, y: -1.0) position = movements.inject(Origin) do |p, (field, delta)| p.with(field => p.send(field) + delta) end ``` ## Proposed detail: Call this method: `#with` ```ruby Money = Data.define(:amount, :currency) account = Money.new(amount: 100, currency: 'USD') transactions = [+10, -5, +15] account = transactions.inject(account) { |a, t| a.with(amount: a.amount + t) } #=> Money(amount: 120, currency: "USD") ``` ## Why add this "Copy with changes" method to the Data simple immutable value class? Called on an instance, it returns a new instance with only the provided parameters changed. This API affordance is now **widely adopted across many languages** for its usefulness. Why is it so useful? Because copying immutable value object instances, with 1 or more discrete changes to specific fields, is the proper and ubiquitous pattern that takes the place of mutation when working with immutable value objects. **Other languages** C# Records: “immutable record structs — Non-destructive mutation” — is called `with { ... }` https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-t… Scala Case Classes — is called `#copy` https://docs.scala-lang.org/tour/case-classes.html Java 14+ Records — Brian Goetz at Oracle is working on adding a with copy constructor inspired by C# above as we speak, likely to be called `#with` https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html Rust “Struct Update Syntax” via `..` syntax in constructor https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-insta… ## Alternatives Without a copy-with-changes method, one must construct entirely new instances using the constructor. This can either be (a) fully spelled out as boilerplate code, or (b) use a symmetrical `#to_h` to feed the keyword-args constructor. **(a) Boilerplate using constructor** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(x: Origin.x, y: Origin.y, **change) ``` **(b) Using a separately proposed `#to_h` method and constructor symmetry** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(**(Origin.to_h.merge(change))) ``` Notice that the above are not ergonomic -- leading so many of our peer language communities to adopt the `#with` method to copy an instance with discrete changes. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111177] [Ruby master Feature#17325] Adds Fiber#cancel, which forces a Fiber to break/return
by nevans (Nicholas Evans) 03 Dec '22

03 Dec '22

Issue #17325 has been updated by nevans (Nicholas Evans). oh, I still very much want the "break"/"return" semantic, and I still think it should be invoked via Fiber#cancel (not a special exception class with Fiber#raise). But I think the semantics and implementation should be slightly different from this proposal (I don't have time to put together a new proposal before 3.2). So I closed the associated PR. But we could leave the ticket open, at least until it is superceded by a better proposal. ---------------------------------------- Feature #17325: Adds Fiber#cancel, which forces a Fiber to break/return https://bugs.ruby-lang.org/issues/17325#change-100461 * Author: nevans (Nicholas Evans) * Status: Open * Priority: Normal ---------------------------------------- Calling `Fiber#cancel` will force a fiber to return, skipping rescue and catch blocks but running all ensure blocks. It behaves as if a `break` or `return` were used to jump from the last suspension point to the top frame of the fiber. Control will be transferred to the canceled fiber so it can run its ensure blocks. ## Propagation from resuming to resumed fibers Any non-root living fiber can be canceled and cancellation will propagate to child (resumed) fibers. In this way, a suspended task can be canceled even if it is e.g. resuming into an enumerator, and the enumerator will be canceled as well. Transfer of control should match #17221's *(much improved)* transfer/resume semantics. After the cancellation propagates all the way to the bottom of the fiber resume stack, the last fiber in the chain will then be resumed. Resuming fibers will not run until they are yielded back into. ## Suspension of canceled fibers Canceled fibers can still transfer control with `resume`, `yield`, and `transfer`, which may be necessary in order to release resources from `ensure` blocks. For simplicity, subsequent cancels will behave similarly to calling `break` or `return` inside an `ensure` block, and the last cancellation reason will overwrite earlier reasons. ## Alternatives `Fiber#raise` could be used, but: * Can only raise on resumable fibers. * Cannot propagate cancellation down to resumed fibers. * Exceptions are bigger and slower than `break`. * `#raise` can't (and shouldn't) be sent to resuming fibers. (It can't propagate.) * Exceptions can be caught. This might be desirable, but that should be at the discretion of the calling fiber. Catch/Throw could be used (with an anonymous `Object.new`), but: * We would need to add `Fiber#throw` (or wrap/intercept `Fiber.yield`). * A hypothetical `Fiber#throw` should probably have similar semantics to `#resume` and thus only be allowed on resumable fibers. * In that case, it wouldn't propagate down to resumed fibers. * `catch` adds an extra stack frame. We could use go-style "Context" objects that contain a "done?" queue/future. * These would need to be explicitly passed around. * Although their usage could be enforced via linters like rubocop, I think that placing it off to the side will give developers the impression that it is optional Some sort of cancel propagation mechanism is not optional for structured concurrency. * It should built into any task-scheduler library, which would allow application code to use it explicitly. * But this suffers the same problem as current Fiber wrappers: it works fine if your code uses the wrapper, but code that uses fibers without the wrapper can be incompatible and introduce bugs (e.g. fibers that are released without running their `ensure` blocks). * This make sense for a language like go which doesn't have exceptions but does have a convention of returning an "error" value. It feels out of place in ruby, IMO. Letting the fiber-task-scheduler mitigates that... for code that uses the fiber-task-scheduler. We could add a keyword option to `Fiber#raise` that gives it similar propagation semantics to this. * IMO, the simplicity of `Fiber#raise` simply being a specialized version of `Fiber#resume` is worth preserving. * The propagation changes alone are enough of a semantic difference to warrant a new method. We could implement `Fiber#cancel` by using `fiber.raise(FiberCancellationError)` on the bottom fiber and catching that exception during termination of the canceled fiber. * This would have the "benefit" that the exception could be rescued. * I might be wrong, but I think that doing this would mostly duplicate my PR, but with some added complexity around exception construction and catching. * It might be a good keyword option? e.g. `Fiber#cancel(with_exception: [true,#exception,#to_str])` Just let the task-fiber-scheduler library handle this. * That's what I'm already doing now. It's mostly fine. It works in my code. * Putting it into ruby core should lead to a small performance boost on very commonly repeated code. * There's probably a better way to store the `cancel_reason` that doesn't require the overhead of adding another `VALUE` to `rb_fiber_struct`. Maybe it can be placed directly into `errinfo`? * Although the common cases can be handled via a trampoline fiber or #17221, there can still be situations where your application's fiber-scheduler library might not know about fibers created by other libraries. This adds interoperability to a common scenario. * Coroutine cancellation is IMO a core feature. It's important to have something like this for all applications and libraries to use as a baseline for interoperability. Implementation: https://github.com/ruby/ruby/pull/3766 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111176] [Ruby master Feature#19000] Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object]
by austin (Austin Ziegler) 03 Dec '22

03 Dec '22

Issue #19000 has been updated by austin (Austin Ziegler). ufuk (Ufuk Kayserilioglu) wrote in #note-31: > RubyBugs (A Nonymous) wrote in #note-29: > > As another reference point: in Scala `case class` this operation is called `#copy`, and I think it returns the original object instance in the no-args case. > > https://docs.scala-lang.org/tour/case-classes.html > > Indeed, it was along these lines that I'd suggested `dup` originally. Like I've said before, I am flexible on what the name should be and `copy` actually addresses the naming concern equally as well as `dup` in my opinion. It also makes sense to ask for a "copy" with no values changed and readability is not hurt in any way. I think that `#copy` is OK, but this is more of a (checked?) `#merge`, right? I think that would be where my question comes in. If `origin` is a `Point` containing `x` and `y` values, then `origin#copy(x: 1, y: 2, z: 3)` should do…what? Should it error or just take the values that it knows? Because the *shape* provided to `#copy` is no longer a `Point` shape. ---------------------------------------- Feature #19000: Data: Add "Copy with changes method" [Follow-on to #16122 Data: simple immutable value object] https://bugs.ruby-lang.org/issues/19000#change-100460 * Author: RubyBugs (A Nonymous) * Status: Open * Priority: Normal ---------------------------------------- *As requested: extracted a follow-up to #16122 Data: simple immutable value object from [this comment](http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/109815)* # Proposal: Add a "Copy with changes" method to Data Assume the proposed `Data.define` exists. Seeing examples from the [[Values gem]](https://github.com/ms-ati/Values): ```ruby require "values" # A new class Point = Value.new(:x, :y) # An immutable instance Origin = Point.with(x: 0, y: 0) # Q: How do we make copies that change 1 or more values? right = Origin.with(x: 1.0) up = Origin.with(y: 1.0) up_and_right = right.with(y: up.y) # In loops movements = [ [ :x, +0.5 ], [ :x, +0.5 ], [ :y, -1.0 ], [ :x, +0.5 ], ] # position = Point(x: 1.5, y: -1.0) position = movements.inject(Origin) do |p, (field, delta)| p.with(field => p.send(field) + delta) end ``` ## Proposed detail: Call this method: `#with` ```ruby Money = Data.define(:amount, :currency) account = Money.new(amount: 100, currency: 'USD') transactions = [+10, -5, +15] account = transactions.inject(account) { |a, t| a.with(amount: a.amount + t) } #=> Money(amount: 120, currency: "USD") ``` ## Why add this "Copy with changes" method to the Data simple immutable value class? Called on an instance, it returns a new instance with only the provided parameters changed. This API affordance is now **widely adopted across many languages** for its usefulness. Why is it so useful? Because copying immutable value object instances, with 1 or more discrete changes to specific fields, is the proper and ubiquitous pattern that takes the place of mutation when working with immutable value objects. **Other languages** C# Records: “immutable record structs — Non-destructive mutation” — is called `with { ... }` https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-t… Scala Case Classes — is called `#copy` https://docs.scala-lang.org/tour/case-classes.html Java 14+ Records — Brian Goetz at Oracle is working on adding a with copy constructor inspired by C# above as we speak, likely to be called `#with` https://mail.openjdk.org/pipermail/amber-spec-experts/2022-June/003461.html Rust “Struct Update Syntax” via `..` syntax in constructor https://doc.rust-lang.org/book/ch05-01-defining-structs.html#creating-insta… ## Alternatives Without a copy-with-changes method, one must construct entirely new instances using the constructor. This can either be (a) fully spelled out as boilerplate code, or (b) use a symmetrical `#to_h` to feed the keyword-args constructor. **(a) Boilerplate using constructor** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(x: Origin.x, y: Origin.y, **change) ``` **(b) Using a separately proposed `#to_h` method and constructor symmetry** ```ruby Point = Data.define(:x, :y, :z) Origin = Point.new(x: 0.0, y: 0.0, z: 0.0) change = { z: -1.5 } # Have to use full constructor -- does this even work? point = Point.new(**(Origin.to_h.merge(change))) ``` Notice that the above are not ergonomic -- leading so many of our peer language communities to adopt the `#with` method to copy an instance with discrete changes. -- https://bugs.ruby-lang.org/

1 0