local constant
aidy
Could anyone tell me why Ruby does not allow a local constant?
FIREFOX_CLASS = "[CLASS:MozillaUIWindowClass]"
Thank You
Aidy
David A. Black
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!
aidy
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
Phlip
> 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
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
Robert Dober
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.
--
Ernest Hemingway
Phlip
>>> 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
Marc Heiler
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/.
Phlip
>> 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
David A. Black
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:
Robert Dober
> 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.
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.
Phlip
> 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
David A. Black
On Sun, 27 Jul 2008, Phlip wrote:
> 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.