Project

General

Profile

Actions

Feature #14397

open

public, protected and private should return their arguments instead of self

Added by usa (Usaku NAKAMURA) about 6 years ago. Updated over 5 years ago.

Status:
Assigned
Target version:
-
[ruby-core:85079]

Description

Matsuda-san suggested me that public, protected and private should return their arguments instead of self,
to write such code:`

require "finalist"
# see https://github.com/joker1007/finalist

class Foo
  extend Finalist

  final private def foo
  end
end

I believe that it's reasonable request, and also believe that there is no product code which uses the return values of public, protected and private.
Matz, how do you think about this change?
The patch is attached.


Files

return_values_of_visibility_methods.diff (7.47 KB) return_values_of_visibility_methods.diff usa (Usaku NAKAMURA), 01/24/2018 09:25 PM

Related issues 2 (0 open2 closed)

Related to Ruby master - Feature #11541: Let attr_accessor, _reader & _writer return symbols of the defined methodsClosedActions
Has duplicate Ruby master - Feature #14396: public, protected and private should return their arguments instead of selfRejectedmatz (Yukihiro Matsumoto)Actions
Actions #1

Updated by usa (Usaku NAKAMURA) about 6 years ago

  • Has duplicate Feature #14396: public, protected and private should return their arguments instead of self added
Actions #2

Updated by Eregon (Benoit Daloze) about 6 years ago

  • Related to Feature #11541: Let attr_accessor, _reader & _writer return symbols of the defined methods added

Updated by Eregon (Benoit Daloze) about 6 years ago

Would it be simpler for the semantics to always return an Array of symbols?
Otherwise final (and other potential uses) has to handle both a single Symbol and an Array of Symbol.

One concern is the extra allocations for the common case of a single argument given to private.

Actions #4

Updated by naruse (Yui NARUSE) over 5 years ago

  • Target version deleted (2.6)
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0