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/

Issue #20202 has been updated by matheusrich (Matheus Richard). @palkan made it possible to play with [what this feature would look like](https://ruby-next.github.io/#gist:bf3a796268a9730a095fb26cf7f51410) via Ruby Next. ---------------------------------------- Feature #20202: Memoized endless method definitions https://bugs.ruby-lang.org/issues/20202#change-106620 * 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/

Issue #20202 has been updated by systho (Philippe Van Eerdenbrugghe). (I'm not a frequent user of this board, I hope it is okay to comment on a closed ticket) I believe there is a significant use case for this feature idea because it reveals something about the intention in a more terser way, and therefore less noisy. Memoization is a frequent enough intention and the most frequent pattern for implementing it is `@current_method_name ||= compute_value ` This pattern is frequently not usable because of 2 reasons : - A) The computation does not hold in a one-liner - B) The result is a boolean (or anything that can be evaluated to false by || operator) Case A does not really interest us here since endless methods are mostly about one-liners. Case B is usually solved by using a different pattern : ``` def my_method return @my_method if defined?(@my_method) @my_method = compute_boolean_value end ``` which turns case B into a multiliner and therefore prevents it being written as an endless method. This is even worse with most style guidelines forcing a blank line after an early return statement, which is also quite frequent. An additional issue happens when working in teams that will force the usage of `defined?(@ivar)` as the only valid way to do memoizing in order to maximize consistency within the team. Because of these reasons, the memoization *intention* gets lost in noisy boilerplate and I believe this feature idea (or anything that would allow marking the memoization intention at the signature level) has a valid use case. The two other bullet points about the method set are beyond my understanding so I cannot propose an argument. There is an issue which has not been mentioned though : memoization is rather easy for method without arguments called on immutable objects. But it becomes much more complex when those criteria are not met. I do not know how realistic it would be to implement this feature in a way that would gracefully fail when some conditions are not met. ---------------------------------------- Feature #20202: Memoized endless method definitions https://bugs.ruby-lang.org/issues/20202#change-112135 * Author: matheusrich (Matheus Richard) * Status: Rejected ---------------------------------------- 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/