Project

General

Profile

Feature #16615

Group style access scope for macros

Added by ted (Ted Johansson) 10 months ago. Updated 9 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
[ruby-core:97088]

Description

Given a method .bar, which defines an instance method #baz on a class, and returns the defined method's name as a symbol (:baz).

class Foo

  private

  # On evaluation defines a method and returns its name.
  # In current Ruby, that method will be public. The suggested
  # behaviour is to make it private, since the class method
  # which defines the instance method is in the private scope.
  #
  bar :baz
end

it would be neat if the dynamically defined instance method respected the scope in which its definition originated. (In this particular case private.)

Essentially the request is to extend the special powers of attr_* (being able to define methods that honour visibility scopes) to any method.

Note: I am aware that inline access scopes already work for dynamically defined methods, as they merely accept a symbol as an argument.

Edit: Changed macro to bar so people don't get hung up on the name of the method (which has no importance to the proposal.)

Updated by shevegen (Robert A. Heiler) 10 months ago

The suggestion is fairly short; might help to expand a bit, in particular why it would be
necessary/useful.

Two comments from me in regards to the proposal:

1) Is there a defining difference towards e. g. the attr* family? Perhaps I missed this
in the proposal, but it should be remembered, even more so as this may become a question
to newcomers for ruby - see the old questio about "Symbol versus String" and strange
add-ons such as HashWithIndifferentAccess.

2) I believe the name "macro" is an awkward name. I am not sure that name should be added,
but even more importantly the relatedness to 1) should be considered. (The public versus
private distinction in ruby is not a strong one, due to ruby's dynamic nature and
philosophy. I understand why the distinction is there, but personally I very, very
rarely use public/private ever; if then mostly just to portray intention to others
in a libary, but even then I often wonder whether this is even necessary. I think it
then comes down a lot to the personal preferences of a given ruby user more than
anything else.).

Updated by shan (Shannon Skipper) 10 months ago

The idea of attrs returning a Symbol was rejected in: https://bugs.ruby-lang.org/issues/9453

Your example doesn't seem to be a macro. How does this differ from attrs?

#3

Updated by ted (Ted Johansson) 9 months ago

  • Description updated (diff)
#4

Updated by ted (Ted Johansson) 9 months ago

  • Description updated (diff)

Updated by ted (Ted Johansson) 9 months ago

shevegen (Robert A. Heiler) wrote in #note-1:

Two comments from me in regards to the proposal:

1) Is there a defining difference towards e. g. the attr* family? Perhaps I missed this
in the proposal, but it should be remembered, even more so as this may become a question
to newcomers for ruby - see the old questio about "Symbol versus String" and strange
add-ons such as HashWithIndifferentAccess.

The attr_* family of methods currently enjoys special treatment here, as they are the only methods
which define instance methods that will obey this style of visibility scope.

2) I believe the name "macro" is an awkward name. I am not sure that name should be added,
but even more importantly the relatedness to 1) should be considered.

I changed the name to a meta-syntactic variable, since it's irrelevant to the proposal itself.

(The public versus private distinction in ruby is not a strong one, due to ruby's dynamic
nature and philosophy. [...] I think it then comes down a lot to the personal preferences
of a given ruby user more than anything else.).

I think you might be projecting your personal opinion onto "Ruby in general". I can't think
of any library which doesn't make extensive use of encapsulation. (For example, Rails has
1,073 uses of private.) Not saying you have todo it in your projects, but it is a thing, and in my
experience working with large code bases, it's also a Good Thing™. :-)

Updated by Dan0042 (Daniel DeLorme) 9 months ago

  • Description updated (diff)

Maybe a more concrete example would be helpful:

def defc
  define_method(:c){ }
end
class Foo
  private
  def a; end
  attr_accessor :b
  defc
end
Foo.new.a #=> NoMethodError (private method `a' called)
Foo.new.b #=> NoMethodError (private method `b' called)
Foo.new.c #=> nil

Having c be declared as private may be desirable... but there's sure to be a compatibility impact.

Is that why you added the condition that this should only happen if the meta-method (bar / defc) returns the instance method name (baz / c) as a symbol?

Also available in: Atom PDF