Bug #796
closeddynamic constant assignment
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
Updated by tmat (Tomas Matousek) almost 16 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
Updated by matz (Yukihiro Matsumoto) almost 16 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
Updated by matz (Yukihiro Matsumoto) almost 16 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
Updated by matz (Yukihiro Matsumoto) almost 16 years ago
- Status changed from Open to Closed
=begin
=end
Updated by jredville (Jim Deville) almost 16 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 assignmentHi,
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 assignmentYou 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
Updated by matz (Yukihiro Matsumoto) almost 16 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
Updated by trans (Thomas Sawyer) almost 16 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_setPlease 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
Updated by antares (Michael Klishin) almost 16 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
Updated by matz (Yukihiro Matsumoto) almost 16 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