[#111472] [Ruby master Bug#19274] Error installing ruby 3.2.0 on RH 8 — "aalllop (Alberto Allegue) via ruby-core" <ruby-core@...>
Issue #19274 has been reported by aalllop (Alberto Allegue).
5 messages
2022/12/28
[#111508] Data support for versions before 3.2.0 — Eustáquio Rangel via ruby-core <ruby-core@...>
I was wondering that every piece of code (gems, etc) that use the new Data =
3 messages
2022/12/29
[ruby-core:111512] [Ruby master Bug#19278] Constructing subclasses of Data with positional arguments
From:
"zverok (Victor Shepelev) via ruby-core" <ruby-core@...>
Date:
2022-12-29 20:28:39 UTC
List:
ruby-core #111512
Issue #19278 has been updated by zverok (Victor Shepelev).
@tenderlove I assure you that I spent a lot of time thinking about possible design decisions, and I believe that while _somewhat unlike_ other classes, the current choice is the best in usability. It is documented (the documentation might emphasize the design choice more, with that I might agree).
The constraints I was working is was:
* flexible creation (e.g. `Point.new(1, 2)` and `Point.new(x: 1, y: 2)` both works)
* as clear error indication with wrong arguments as possible without creating a whole framework for "explanatory errors" (think Rust)
* ease of updating `initialize` protocol for the end user (providing defaults and conversions).
If you have better idea of how to achieve it, I will gladly consider it.
That being said, I believe that "it was surprising on the first pass" does not _necessarily_ equal "ruins usability", and the gains are more than losses.
> Also inheriting from a Data class seems kind of an anti/rare pattern.
I don't think it is 100% true (especially if we'll consider `Data.define(...) do` as an inheritance). At least, even in pre-`Data` times, I have a fair share of usages doing nice things like
```ruby
class Point < Struct.new(:x, :y)
def distance_to(other)
# ...
end
end
```
I think "immutable value objects" doesn't imply "no additional convenience querying methods".
And, as I said, the `new`/`initialize` pair was **specifically** designed for usability on inheritance (or `do`-block-inheritance).
When we discussed the initial protocol, Matz was concerned about the ability to provide defaults for _some_ fields (like some additional API maybe, like `Data.define(:x, :y, z: 0)` (which looks nice, but has some grave problems), and I believe that this example provides a clear and usable compromise:
```ruby
class Point < Data.define(:x, :y, :z)
def initialize(x:, y:, z: 0) = super
end
```
That is intended.
`Data` is a new thing. It has its quirks, but we put a lot into designing it as a small, easy-to-learn, and convenient API.
----------------------------------------
Bug #19278: Constructing subclasses of Data with positional arguments
https://bugs.ruby-lang.org/issues/19278#change-100882
* Author: tenderlovemaking (Aaron Patterson)
* Status: Feedback
* Priority: Normal
* ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin22]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
I'd expect both of the following subclasses to work, but the subclass that uses positional parameters raises an exception:
```ruby
Foo = Data.define
class Bar < Foo
def initialize foo:
p foo
end
end
class Baz < Foo
def initialize foo
p foo
end
end
Bar.new foo: 1 # Prints 1
Baz.new 1 # Raises ArgumentError
```
I'd expect the subclass that uses positional arguments to work.
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/