[#116016] [Ruby master Bug#20150] Memory leak in grapheme clusters — "peterzhu2118 (Peter Zhu) via ruby-core" <ruby-core@...>
Issue #20150 has been reported by peterzhu2118 (Peter Zhu).
7 messages
2024/01/04
[#116382] [Ruby master Feature#20205] Enable `frozen_string_literal` by default — "byroot (Jean Boussier) via ruby-core" <ruby-core@...>
Issue #20205 has been reported by byroot (Jean Boussier).
77 messages
2024/01/23
[ruby-core:116372] [Ruby master Feature#20202] Memoized endless method definitions
From:
"rubyFeedback (robert heiler) via ruby-core" <ruby-core@...>
Date:
2024-01-22 19:56:54 UTC
List:
ruby-core #116372
Issue #20202 has been updated by rubyFeedback (robert heiler).
matheusrich wrote:
> it's also a common pattern on Ruby codebases
I am not sure it is that common. It is perhaps more common in
rails-specific code. For other regular ruby gems out there,
I don't see that many use endless methods nor memoization
(though admittedly I see more memoization than endless method
definitions; this could perhaps be explained by endless method
definitions being still fairly young, and many gem authors
prefer to not be "too quickly" on the most recent ruby version.
Rubular, for instance, still uses Ruby 2.5.9, oddly enough).
Personally I also find endless method definitions harder to
read; I kind of have to look more to the right side, whereas
in regular ruby code with "def foo; end", the latter being on
the same indent level as "def", I kind of look more towards the
left side, and the bottom area below "def". I am rather used
to seeing "def foo; end", although years ago I actually wanted
to see how ruby code would "feel" when we can omit end, like
in python (but without the mandatory ":").
I did not have endless method in mind when I wanted this, though,
and I kind of adjusted to having to type "end".
For instance:
def settings = @settings ||= Settings.new(self)
def notifications? = @notifications
I find this condensed variant harder to read.
Personally I am also interested in sawa's opinion about
the proposal here, as he recently suggested a shortcut
definition for endless method definitions (e. g. by
omitting "def").
> In the example, the settings method could be rewritten as
> def settings ||= Settings.new(self)
I kind of understand your point of view there and it would
omit some typing to do, right? So this may just be a different
style of writing ruby code. Personally, though, I am not a
big fan of these condensed one-liner variants.
----------------------------------------
Feature #20202: Memoized endless method definitions
https://bugs.ruby-lang.org/issues/20202#change-106389
* Author: matheusrich (Matheus Richard)
* Status: Open
* Priority: Normal
----------------------------------------
I propose introducing a shorthand for memoized endless method definitions:
```rb
class Foo
def bar ||= :memoized_value
# It should behave like
def bar = (@bar ||= :memoized_value)
end
```
Not only is this shorter and (IMO) a natural follow-up for endless method definitions, but it's also a common pattern on Ruby codebases. It's very useful to decompose responsibilities into several objects:
```rb
class User
def notifications_enabled? = settings.notifications?
def enable_notifications = (settings.notifications = true)
def disable_notifications = (settings.notifications = false)
private
def settings = @settings ||= Settings.new(self)
end
class User::Settings
attr_writer :notifications
def initialize(user)
@user = user
@notifications = false
end
def notifications? = @notifications
end
u = User.new
u.notifications_enabled? # => false
u.enable_notifications
u.notifications_enabled? # => true
```
In the example, the `settings` method could be rewritten as
```rb
def settings ||= Settings.new(self)
```
--
https://bugs.ruby-lang.org/
______________________________________________
ruby-core mailing list -- ruby-core@ml.ruby-lang.org
To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/