- ruby-core - ml.ruby-lang.org

[ruby-core:111208] [Ruby master Feature#19183] Add bin/goruby, bin/ruby, and lib/libruby.so.3.2.0 (or similar) to .gitignore
by duerst 05 Dec '22

05 Dec '22

Issue #19183 has been reported by duerst (Martin Dürst). ---------------------------------------- Feature #19183: Add bin/goruby, bin/ruby, and lib/libruby.so.3.2.0 (or similar) to .gitignore https://bugs.ruby-lang.org/issues/19183 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal ---------------------------------------- When I compile ruby, and then use `git status`, the files `bin/goruby`, `bin/ruby`, and `lib/libruby.so.3.2.0` (or similar) always show up as untracked files. I think they should be added to .gitignore. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111181] [Ruby master Feature#19177] optional offset for Array#index
by Dan0042 (Daniel DeLorme) 05 Dec '22

05 Dec '22

Issue #19177 has been reported by Dan0042 (Daniel DeLorme). ---------------------------------------- Feature #19177: optional offset for Array#index https://bugs.ruby-lang.org/issues/19177 * Author: Dan0042 (Daniel DeLorme) * Status: Open * Priority: Normal ---------------------------------------- String#index allows an optional offset: ```ruby "the quick brown fox jumps over the lazy dog".index("the") #=> 0 "the quick brown fox jumps over the lazy dog".index("the",1) #=> 31 ``` I was a bit surprised that Array doesn't support this and I feel it would be a very natural addition: ```ruby %w[the quick brown fox jumps over the lazy dog].index("the") #=> 0 %w[the quick brown fox jumps over the lazy dog].index("the",1) #=> 6 instead of ArgumentError ``` -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111206] [Ruby master Feature#16122] Data: simple immutable value object
by matz (Yukihiro Matsumoto) 05 Dec '22

05 Dec '22

Issue #16122 has been updated by matz (Yukihiro Matsumoto). I propose a little bit different approach: ```ruby Ticket = Data.define(:event_id, :user_id,:start_at) do # And other methods defined below def validate puts "Validated!" end end ``` This is much consistent and work now without any enhancement. Matz. ---------------------------------------- Feature #16122: Data: simple immutable value object https://bugs.ruby-lang.org/issues/16122#change-100496 * 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:111205] [Ruby master Bug#19182] ALWAYS_UPDATE_UNICODE=yes downloads all the Unicode files twice when executing make
by duerst 05 Dec '22

05 Dec '22

Issue #19182 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #19182: ALWAYS_UPDATE_UNICODE=yes downloads all the Unicode files twice when executing make https://bugs.ruby-lang.org/issues/19182 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 3.2.0dev (2022-12-04T20:23:09Z master d90835aeb5) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- `make` downloads all the Unicode files twice when ALWAYS_UPDATE_UNICODE is set to yes. One download is for miniruby, the second is for ruby. This shouldn't be necessary. I hope this can be fixed. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111204] [Ruby master Bug#19181] lib/unicode-normalize/tables.rb does not get updated even if ALWAYS_UPDATE_UNICODE is set to yes
by duerst 05 Dec '22

05 Dec '22

Issue #19181 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #19181: lib/unicode-normalize/tables.rb does not get updated even if ALWAYS_UPDATE_UNICODE is set to yes https://bugs.ruby-lang.org/issues/19181 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 3.2.0dev (2022-12-04T20:23:09Z master d90835aeb5) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- To update lib/unicode-normalize/tables.rb to Unicode version 15.0.0, I had to manually remove this file. This should not be necessary. Also, it should not be necessary to have to set ALWAYS_UPDATE_UNICODE to yes just to update this file. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111203] [Ruby master Bug#19180] rbconfig.rb does not get updated when common.mk is changed
by duerst 05 Dec '22

05 Dec '22

Issue #19180 has been reported by duerst (Martin Dürst). ---------------------------------------- Bug #19180: rbconfig.rb does not get updated when common.mk is changed https://bugs.ruby-lang.org/issues/19180 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 3.1.0dev (2021-06-03T06:59:33Z master 7e14762159) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I changed UNICODE_VERSION in common.mk to 15.0.0, and ran `make up`, `make`, `make runnable`, and various tests several times. Still rbconfig.rb, and therefore `RbConfig::CONFIG["UNICODE_VERSION"]`, says that the Unicode version is 14.0.0. There seems to be a missing dependency of rbconfig.rb on common.mk somewhere in the makefiles, please add such a dependency. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111202] [Ruby master Bug#18623] `make runnable` does not work
by duerst 04 Dec '22

04 Dec '22

Issue #18623 has been updated by duerst (Martin Dürst). @nakada: I again hit this. I found out that the solution is easy, just do `make goruby` before using `make runnable`. I propose to add `goruby` to the targets necessary when creating `runnable`, to avoid additional steps and unnecessary confusion. ---------------------------------------- Bug #18623: `make runnable` does not work https://bugs.ruby-lang.org/issues/18623#change-100494 * Author: duerst (Martin Dürst) * Status: Open * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 3.1.0dev (2021-06-03T06:59:33Z master 7e14762159) [x86_64-linux] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- When I try `make runnable` to be able to run individual tests with `.\ruby test/runner.rb ...`, I get the error below. It is important to solve this so I can make progress on Feature #18037. Except for the problem reported at Bug #18614, comprehensive tests such as `make check` work fine. ``` duerst@Kloentalersee:~/14ruby$ make runnable BASERUBY = /usr/local/bin/ruby --disable=gems CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O3 -fno-fast-math -ggdb3 -Wall -Wextra -Werror=deprecated-declarations -Werror=div-by-zero -Werror=duplicated-cond -Werror=implicit-function-declaration -Werror=implicit-int -Werror=misleading-indentation -Werror=pointer-arith -Werror=write-strings -Werror=old-style-definition -Wimplicit-fallthrough=0 -Wmissing-noreturn -Wno-cast-function-type -Wno-constant-logical-operand -Wno-long-long -Wno-missing-field-initializers -Wno-overlength-strings -Wno-packed-bitfield-compat -Wno-parentheses-equality -Wno-self-assign -Wno-tautological-compare -Wno-unused-parameter -Wno-unused-value -Wsuggest-attribute=format -Wsuggest-attribute=noreturn -Wunused-variable -Werror=undef -std=gnu99 XCFLAGS = -D_FORTIFY_SOURCE=2 -fstack-protector-strong -fno-strict-overflow -DRUBY_DEVEL=1 -fvisibility=hidden -fexcess-precision=standard -DRUBY_EXPORT -fPIE -I. -I.ext/include/x86_64-linux -I./include -I. -I./enc/unicode/14.0.0 CPPFLAGS = DLDFLAGS = -Wl,--compress-debug-sections=zlib -fstack-protector-strong -pie SOLIBS = -lz -lpthread -lrt -lrt -lgmp -ldl -lcrypt -lm LANG = C.UTF-8 LC_ALL = LC_CTYPE = MFLAGS = gcc (Ubuntu 9.4.0-1ubuntu1~20.04) 9.4.0 Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ln -f goruby ./bin/goruby /home/duerst/14ruby/lib/fileutils.rb:301:in `link': No such file or directory @ rb_file_s_link - (goruby, ./bin/goruby) (Errno::ENOENT) from /home/duerst/14ruby/lib/fileutils.rb:301:in `block in ln' from /home/duerst/14ruby/lib/fileutils.rb:1593:in `fu_each_src_dest0' from /home/duerst/14ruby/lib/fileutils.rb:299:in `ln' from /home/duerst/14ruby/lib/fileutils.rb:1695:in `ln' from ./tool/mkrunnable.rb:59:in `ln_exe' from ./tool/mkrunnable.rb:96:in `ln_relative' from ./tool/mkrunnable.rb:131:in `block in <main>' from ./tool/mkrunnable.rb:128:in `map' from ./tool/mkrunnable.rb:128:in `<main>' make: *** [uncommon.mk:872: runnable] Error 1 duerst@Kloentalersee:~/14ruby$ ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:111201] [Ruby master Feature#10343] Postfix notations for `when` and `else` inside `case` statement
by sawa (Tsuyoshi Sawada) 04 Dec '22

04 Dec '22

Issue #10343 has been updated by sawa (Tsuyoshi Sawada). After eight years, I still think this would be a good feature. Any opinions? ---------------------------------------- Feature #10343: Postfix notations for `when` and `else` inside `case` statement https://bugs.ruby-lang.org/issues/10343#change-100492 * Author: sawa (Tsuyoshi Sawada) * Status: Open * Priority: Normal ---------------------------------------- In a `case` statement, the condition part in the branches do not have the same length in general, and especially, `else` is much shorter than the conditions (`when ...`). So when we write the condition and the return value in a single line, they are not aligned, and are hard to read. ```ruby case foo when some_very_long_condition then "a" when short_cond then "bb" when some_long_condition then "ccc" else "dddd" end ``` I propose to allow postfix notations with `when` and `else` (or `otherwise`) inside `case` statement as below: ```ruby case foo "a" when some_very_long_proc "bb" when short_regex "ccc" when some_long_regex "dddd" else end ``` Pros are: 1) Postfix notation does not require `then` or `;`, so it is concise. 2) The return values from the branches (e.g., `"a"`, `"bb"`, `"ccc"`, `"dddd"`) tend to be shorter and more uniformly lengthened than the conditions, hence they are somewhat close to being aligned naturally, making this easier to read. 3) We are usually more interested in the return value than the condition of a branch, especially when we are reading someone's code and are trying to grasp what the `case` statement does or returns. 4) This notation is closer to case-like conditional notations regularly used in mathematics: ``` ┌ 1 (x = 0) x! = │ └ x (x - 1)! (otherwise) ``` So it would be easier to read for those who are familiar with mathematics. -- https://bugs.ruby-lang.org/

1 0

[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