Project

General

Profile

Bug #796

dynamic constant assignment

Added by Francoys_Proulx (Francois Proulx) almost 11 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
Backport:
[ruby-core:20091]

Description

=begin
I understand the difference in the use of variable and constant. But sometime you need to be able to assigned a value dynamiquely when you are initializing your application. I see 2 possibility to address the problem:

  • a interpreter's directive (which would demand a major change of the interpreter)
  • a method to allow specificely a dynamic assignment =end

History

#1

Updated by tmat (Tomas Matousek) almost 11 years ago

=begin
The error is reported e.g. in this case:

def foo
C = 1
end

SyntaxError: (irb):2: dynamic constant assignment

but is not reported if eval is used. This works:

def foo
eval('C = 1')
end

The restriction is IMO unnecesary and should be removed. If there is a good reason for keeping it it should be consistently applied in eval as well.

=end

#2

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

=begin
Hi,

In message "Re: [ruby-core:20093] [Bug #796] dynamic constant assignment"
on Wed, 26 Nov 2008 03:28:30 +0900, Tomas Matousek redmine@ruby-lang.org writes:

|The restriction is IMO unnecesary and should be removed. If there is a good reason for keeping it it should be consistently applied in eval as well.

Why?

According to the nature of CONSTANTS, it's bit weird to allow dynamic
assignment, since we report error. eval is kinda like a back door.
We assume a user of eval knows what he's doing.

                        matz.

=end

#3

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

=begin
Hi,

In message "Re: [ruby-core:20091] [Bug #796] dynamic constant assignment"
on Wed, 26 Nov 2008 03:05:12 +0900, Francois Proulx redmine@ruby-lang.org writes:

|I understand the difference in the use of variable and constant. But sometime you need to be able to assigned a value dynamiquely when you are initializing your application. I see 2 possibility to address the problem:
|
|- a interpreter's directive (which would demand a major change of the interpreter)
|- a method to allow specificely a dynamic assignment

You have Module#const_set, and to avoid duplicate assignment warning,
you need to remove the old constant first by Module#remove_const.

                        matz.

=end

#4

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

  • Status changed from Open to Closed

=begin

=end

#5

Updated by jredville (Jim Deville) almost 11 years ago

=begin

-----Original Message-----
From: Yukihiro Matsumoto [mailto:matz@ruby-lang.org]
Sent: Tuesday, November 25, 2008 10:39 AM
To: ruby-core@ruby-lang.org
Subject: [ruby-core:20095] Re: [Bug #796] dynamic constant assignment

Hi,

In message "Re: [ruby-core:20091] [Bug #796] dynamic constant
assignment"
on Wed, 26 Nov 2008 03:05:12 +0900, Francois Proulx writes:

|I understand the difference in the use of variable and constant. But
sometime you need to be able to assigned a value dynamiquely when you
are initializing your application. I see 2 possibility to address the
problem:
|
|- a interpreter's directive (which would demand a major change of the
interpreter)
|- a method to allow specificely a dynamic assignment

You have Module#const_set, and to avoid duplicate assignment warning,
you need to remove the old constant first by Module#remove_const.

                                                    matz.

What about a conditional dynamic assignment. It would be nice to have an idiom such as:

CONST ||= "foo"

I've wanted this in the initializer before, and I end up using a ternary and Module#const_set

=end

#6

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

=begin
Hi,

In message "Re: [ruby-core:20096] Re: [Bug #796] dynamic constant assignment"
on Wed, 26 Nov 2008 03:42:29 +0900, Jim Deville jdeville@microsoft.com writes:

|What about a conditional dynamic assignment. It would be nice to have an idiom such as:
|
|CONST ||= "foo"
|
|I've wanted this in the initializer before, and I end up using a ternary and Module#const_set

Please understand constants are constants. Adding such features might
be useful for some cases, I admit, but it makes constants more and
more like mere variables. In my opinion, making constants mere
variables do not buy you much in the long term.

                        matz.

=end

#7

Updated by trans (Thomas Sawyer) almost 11 years ago

=begin

On Nov 25, 1:53 pm, Yukihiro Matsumoto m...@ruby-lang.org wrote:

Hi,

In message "Re: [ruby-core:20096] Re: [Bug #796] dynamic constant assignment"
    on Wed, 26 Nov 2008 03:42:29 +0900, Jim Deville jdevi...@microsoft.com writes:

|What about a conditional dynamic assignment. It would be nice to have an idiom such as:
|
|CONST ||= "foo"
|
|I've wanted this in the initializer before, and I end up using a ternary and Module#const_set

Please understand constants are constants.  Adding such features might
be useful for some cases, I admit, but it makes constants more and
more like mere variables.  In my opinion, making constants mere
variables do not buy you much in the long term.

Indeed. And yet, I'm not sure what the current middle ground approach
buys us either. You can still change them via remove_const and
const_set, so what's the difference? As far as I can tell, all that
accomplishes is extra hoop jumping by us programmers. It's not like
Ruby's execution is optimized knowing constants won't change.

                trans.

=end

#8

Updated by antares (Michael Klishin) almost 11 years ago

=begin
On 26.11.2008, at 15:05, Trans wrote:

And yet, I'm not sure what the current middle ground approach
buys us either. You can still change them via remove_const and
const_set, so what's the difference?

I agree here, sounds like a safety measure that still can be worked

around,
but changes the behavior of constant assignment a lot of people got

used to.

Do we really need to make this change?

MK

=end

#9

Updated by matz (Yukihiro Matsumoto) almost 11 years ago

=begin
Hi,

In message "Re: [ruby-core:20114] Re: [Bug #796] dynamic constant assignment"
on Wed, 26 Nov 2008 22:05:52 +0900, Trans transfire@gmail.com writes:

|Indeed. And yet, I'm not sure what the current middle ground approach
|buys us either. You can still change them via remove_const and
|const_set, so what's the difference? As far as I can tell, all that
|accomplishes is extra hoop jumping by us programmers. It's not like
|Ruby's execution is optimized knowing constants won't change.

At least we can keep "illusion" of constants being constants for
casual users. And I believe it's a good thing.

                        matz.

=end

Also available in: Atom PDF