Hi,
Could anyone tell me why Ruby does not allow a local constant?
FIREFOX_CLASS = “[CLASS:MozillaUIWindowClass]”
Thank You
Aidy
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
On Jul 26, 3:32 pm, “David A. Black” [email protected] wrote:
Hi David
Thanks for getting back
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?
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
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.
On Jul 26, 4:19 pm, Phlip [email protected] 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.
Aidy
On Sat, Jul 26, 2008 at 5:53 PM, aidy [email protected] wrote:
On Jul 26, 4:19 pm, Phlip [email protected] 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.
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
–
http://ruby-smalltalk.blogspot.com/
There’s no one thing that’s true. It’s all true.
Read my verbiage again.
Not trying to nitpick but I agree with Robert D. 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.
Marc H. wrote:
Read my verbiage again.
Not trying to nitpick but I agree with Robert D. 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…)
Hi –
On Sun, 27 Jul 2008, Phlip wrote:
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
Robert D. 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…
On Sat, Jul 26, 2008 at 6:18 PM, Phlip [email protected] wrote:
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.
–
http://ruby-smalltalk.blogspot.com/
There’s no one thing that’s true. It’s all true.
Hi –
On Sun, 27 Jul 2008, Phlip wrote:
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
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!)