local constant

A

aidy

Hi,

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

FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"

Thank You

Aidy
 
D

David A. Black

Hi --

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!
 
A

aidy

Hi David

Thanks for getting back
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
 
A

aidy

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.

Aidy
 
R

Robert Dober

Excellant explanation.

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
 
P

Phlip

Robert said:
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...
 
M

Marc Heiler

Read my verbiage again.

Not trying to nitpick but I agree with Robert Dober about the
formulation:
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.
 
P

Phlip

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

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...)
 
D

David A. Black

Hi --

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
 
R

Robert Dober

Read my verbiage again.
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.
 
P

Phlip

David said:
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!)
 
D

David A. Black

Hi --

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top