Project

General

Profile

Actions

Feature #16752

open

:private param for const_set

Added by bughit (bug hit) almost 4 years ago. Updated almost 4 years ago.

Status:
Open
Assignee:
-
Target version:
-
[ruby-core:97678]

Description

Defining a private constant should not require two method calls.

You want to encourage private declarations because they communicate intent better and are easier to refactor, two statements discourage it.

Ideally there should be compact syntax for direct private declarations, but that's probably a difficult change.

But const_set :FOO, 1, private: true or const_set :FOO, 1, :private should be trivial


Related issues 1 (0 open1 closed)

Related to Ruby master - Feature #17171: Why is the visibility of constants not affected by `private`?RejectedActions

Updated by sawa (Tsuyoshi Sawada) almost 4 years ago

To be precise, actually,

class A
  FOO = 1
  private_constant :FOO
end  

is not two method calls; it is one assignment and one method call.

Besides that, I don't see that writing:

class A
  const_set :FOO, 1, private: true
end

is any more concise than writing:

class A
  FOO = 1; private_constant :FOO
end  

Updated by tannakartikey (Kartikey Tanna) almost 4 years ago

It might be a little helpful only if we are defining constants dynamically.

Updated by shevegen (Robert A. Heiler) almost 4 years ago

I somewhat agree with sawa here.

This may still leave the issue over whether one may prefer a single line/method
call, but I believe this may largely depend on the use case more (if there is
one). I can understand it to some extent if a ruby user may wish to avoid using
the ";", I sometimes want to avoid ";" too. In these cases, I typically do as
sawa pointed out, and just use a new line. :)

But I don't have any really strong preferences here either way, also because
I do not think I have actually used private_constant so far (did not seem
to be necessary for me). I did, however had, have lots of use cases in the past
for const_set() (or whatever the name was for setting a constant for a
particular "namespace" ... I always mix it up with set_const() which I think
does not exist :P ), and also removing this. There are quite many use
cases for the latter, more than for private*, I think. But your mileage
may vary.

Actions #4

Updated by marcandre (Marc-Andre Lafortune) over 3 years ago

  • Related to Feature #17171: Why is the visibility of constants not affected by `private`? added
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0