From: shevegen@... Date: 2020-02-07T12:48:37+00:00 Subject: [ruby-core:97089] [Ruby master Feature#16615] Group style access scope for macros Issue #16615 has been updated by shevegen (Robert A. Heiler). 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.). ---------------------------------------- Feature #16615: Group style access scope for macros https://bugs.ruby-lang.org/issues/16615#change-84195 * Author: ted (Ted Johansson) * Status: Open * Priority: Normal ---------------------------------------- Given a method `.macro`, which defines an instance method `#bar` on a class, and returns the defined method's name as a symbol (`:bar`). ``` class Foo private macro :bar # On evaluation defines a method and returns its name. end ``` it would be neat if the dynamically defined instance method respected the scope in which its definition originated. (In this particular case `private`.) Note: I am aware that inline access scopes already work for dynamically defined methods, as they merely accept a symbol as an argument. -- https://bugs.ruby-lang.org/ Unsubscribe: