Local constant

ruby-talk
1

Hi,

Could anyone tell me why Ruby does not allow a local constant?

FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"

Thank You

Aidy

2

Hi --

···

On Sat, 26 Jul 2008, aidy wrote:

Hi,

Could anyone tell me why Ruby does not allow a local constant?

FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"

I'm afraid I don't follow. That statement will execute perfectly well.
What exactly are you trying to do?

David

--
Rails training from David A. Black and Ruby Power and Light:
     Intro to Ruby on Rails July 21-24 Edison, NJ
  * Advancing With Rails August 18-21 Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!

3

Hi David

Thanks for getting back

> Hi,

> Could anyone tell me why Ruby does not allow a local constant?

> FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"

I'm afraid I don't follow. That statement will execute perfectly well.
What exactly are you trying to do?

I am a little puzzled

irb(main):001:0> def aidy
irb(main):002:1> FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"
irb(main):003:1> end
SyntaxError: compile error
(irb):2: dynamic constant assignment
FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"
                ^

Thanks

Aidy

···

On Jul 26, 3:32 pm, "David A. Black" <dbl...@rubypal.com> wrote:

On Sat, 26 Jul 2008, aidy wrote:

4

aidy wrote:

irb(main):001:0> def aidy
irb(main):002:1> FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"
irb(main):003:1> end
SyntaxError: compile error
(irb):2: dynamic constant assignment
FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"

The purpose of a constant is to configure two or more methods with the same invariable value. Within one method, there's no difference between assigning a putative local constant, and simply assigning a variable - then not varying it.

Ruby expects to assign constants only once. If you called aidy() twice, the constant would re-assign, and it therefor would not be constant.

Put these rules together, and Ruby can only enforce its constant concept if you can't write them locally.

···

--
   Phlip

5

Excellant explanation.

Aidy

···

On Jul 26, 4:19 pm, Phlip <phlip2...@gmail.com> wrote:

Ruby expects to assign constants only once. If you called aidy() twice, the
constant would re-assign, and it therefor would not be constant.

6

But not quite correct, constants *can* be reassigned all you get is a warning.
Nevertheless I think it is good semantics to forbid constant
assignments in methods. If for one reason or another
you need such a beast you can still do it of course.

def a x; Object.const_set "A", x end
a 42
p A
a 44 # get a warning
p A

HTH
Robert

···

On Sat, Jul 26, 2008 at 5:53 PM, aidy <aidy.lewis@googlemail.com> wrote:

On Jul 26, 4:19 pm, Phlip <phlip2...@gmail.com> wrote:

Ruby expects to assign constants only once. If you called aidy() twice, the
constant would re-assign, and it therefor would not be constant.

Excellant explanation.

--
http://ruby-smalltalk.blogspot.com/

There's no one thing that's true. It's all true.
--
Ernest Hemingway

7

Robert Dober wrote:

Ruby expects to assign constants only once. If you called aidy() twice, the
constant would re-assign, and it therefor would not be constant.

Excellant explanation.

But not quite correct, constants *can* be reassigned all you get is a warning.

Read my verbiage again.

And... constants are only labels. Unless you .freeze their targets, you can .replace them, etc. etc...

One almost misses C++, where they fill the language up with risks and loopholes, all to allow most 'const' things to optimize at compile time without global knowledge...

···

--
   Phlip

8

Read my verbiage again.

Not trying to nitpick but I agree with Robert Dober about the
formulation:

If you called aidy() twice, the constant would re-assign,
and it therefor would not be constant.

constants *can* be reassigned

Especially since the error will happen no matter if the constant already
existed, or did not yet exist.

Ruby allows one to reassign constants freely, while only raising a
warning.
One can even go further and misuse constants as hash/array storage
places and put stuff in or get it out again easily.

Ruby seems to dislike this only if it is done within a method, by
raising the "dynamic constant assignment" error.

···

--
Posted via http://www.ruby-forum.com/\.

9

Sorry if I misunderstood, I have misinterpreted your sentence "it
would not be a constant anymore".
Well it is not a constant.
That was what I meant with not quite correct, I should have used "I do
not completely agree" maybe.
R.

···

On Sat, Jul 26, 2008 at 6:18 PM, Phlip <phlip2005@gmail.com> wrote:

Robert Dober wrote:

Ruby expects to assign constants only once. If you called aidy() twice,
the
constant would re-assign, and it therefor would not be constant.

Excellant explanation.

But not quite correct, constants *can* be reassigned all you get is a
warning.

Read my verbiage again.

--
http://ruby-smalltalk.blogspot.com/

There's no one thing that's true. It's all true.
--
Ernest Hemingway

10

Marc Heiler wrote:

Read my verbiage again.

Not trying to nitpick but I agree with Robert Dober about the formulation:

If you called aidy() twice, the constant would re-assign, and it therefor would not be constant.

The quote depends on magically suspending the Ruby error message. Hence it does not say out-of-the-box Ruby cannot reassign.

(We get reassignments, with their warnings, all the time in Rails, partly due to its Magic Loader facility...)

···

--
   Phlip

11

Hi --

···

On Sun, 27 Jul 2008, Phlip wrote:

Marc Heiler wrote:

Read my verbiage again.

Not trying to nitpick but I agree with Robert Dober about the formulation:

If you called aidy() twice, the constant would re-assign, and it therefor would not be constant.

The quote depends on magically suspending the Ruby error message. Hence it does not say out-of-the-box Ruby cannot reassign.

(We get reassignments, with their warnings, all the time in Rails, partly due to its Magic Loader facility...)

The magic loading shouldn't lead to those errors. It only does the
magic loading for unresolved constant references, and once it loads
the necessary file, any further references to the constant won't be
unresolved.

Maybe you've got some rogue "load" commands somewhere.

David

--
Rails training from David A. Black and Ruby Power and Light:
  * Advancing With Rails August 18-21 Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!

12

David A. Black wrote:

The magic loading shouldn't lead to those errors. It only does the
magic loading for unresolved constant references, and once it loads
the necessary file, any further references to the constant won't be
unresolved.

Maybe you've got some rogue "load" commands somewhere.

See where I said 'partly due'?

There are three kinds of loading:

   require 'foo' # must be on the $: path

   require 'path/to/foo'

   Foo.new # magic loading (via ActiveSupport?)

If the system requires the same file twice thru different paths, it will load the same file twice. The (primitive) require only avoids reloading a file if it sees the exact same path.

The magic loader adds a third system to load - one where the path is invisible. Hence it increases the odds of accidentally reloading a file.

(This is not a request for newb advice, BTW!)

···

--
   Phlip

13

Hi --

David A. Black wrote:

The magic loading shouldn't lead to those errors. It only does the
magic loading for unresolved constant references, and once it loads
the necessary file, any further references to the constant won't be
unresolved.

Maybe you've got some rogue "load" commands somewhere.

See where I said 'partly due'?

There are three kinds of loading:

require 'foo' # must be on the $: path

require 'path/to/foo'

Foo.new # magic loading (via ActiveSupport?)

There's also "load", which will (re)load unconditionally. That's why I
was thinking you might have some of those around.

If the system requires the same file twice thru different paths, it will load the same file twice. The (primitive) require only avoids reloading a file if it sees the exact same path.

So it does. Interesting.

The magic loader adds a third system to load - one where the path is invisible. Hence it increases the odds of accidentally reloading a file.

I guess I try to do one or the other: either an explicit require, or
using the magic loader, but not both, so ideally the warning won't
happen. Then again, it's only a warning, so not too dire if it does
happen.

(This is not a request for newb advice, BTW!)

I'm afraid I don't understand.

David

···

On Sun, 27 Jul 2008, Phlip wrote:

--
Rails training from David A. Black and Ruby Power and Light:
  * Advancing With Rails August 18-21 Edison, NJ
  * Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!