Project

General

Profile

Actions

Bug #796

closed

dynamic constant assignment

Added by Francoys_Proulx (Francois Proulx) over 15 years ago. Updated almost 13 years ago.

Status:
Closed
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
Actions #1

Updated by tmat (Tomas Matousek) over 15 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

Actions #2

Updated by matz (Yukihiro Matsumoto) over 15 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 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

Actions #3

Updated by matz (Yukihiro Matsumoto) over 15 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 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

Actions #4

Updated by matz (Yukihiro Matsumoto) over 15 years ago

  • Status changed from Open to Closed

=begin

=end

Actions #5

Updated by jredville (Jim Deville) over 15 years ago

=begin

-----Original Message-----
From: Yukihiro Matsumoto []
Sent: Tuesday, November 25, 2008 10:39 AM
To:
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 <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.

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

Actions #6

Updated by matz (Yukihiro Matsumoto) over 15 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 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

Actions #7

Updated by trans (Thomas Sawyer) over 15 years ago

=begin

On Nov 25, 1:53 pm, Yukihiro Matsumoto 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 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

Actions #8

Updated by antares (Michael Klishin) over 15 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

Actions #9

Updated by matz (Yukihiro Matsumoto) over 15 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 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

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0