Hi,
Am Dienstag, 22. Dez 2009, 21:59:30 +0900 schrieb Rick DeNatale:
x = “foo”
x.freeze
x.replace “bar” # forbidden (TypeError)No you can’t freeze variables, you can freeze the objects they reference.
Yes, of course. I meant ‘objects in regular, non-constant
variables’. Sorry for the sloppy phrase.
I just detected another thing: It is abolutely pointless to freeze
a symbol object.
Bertram
Should I only use symbols for hash keys and method names?
On Tue, Dec 22, 2009 at 6:02 AM, Bertram S.
[email protected] wrote:
X = “hello”
X = “bye” # not allowed (just a warning)
X.replace “bye” # this is allowed!
X.freeze
X.replace “hi again” # forbidden (TypeError)But you can also freeze other variables:
x = “foo”
x.freeze
x.replace “bar” # forbidden (TypeError)
No you can’t freeze variables, you can freeze the objects they
reference.
ruby-1.8.7-p174 > x = ‘foo’
=> “foo”
ruby-1.8.7-p174 > x.freeze
=> “foo”
ruby-1.8.7-p174 > x = ‘boo’
=> “boo”
ruby-1.8.7-p174 > A = ‘bar’
=> “bar”
ruby-1.8.7-p174 > A.freeze
=> “bar”
ruby-1.8.7-p174 > A = ‘baz’
(irb):6: warning: already initialized constant A
=> “baz”
ruby-1.8.7-p174 > A
=> “baz”
Variables in Ruby are not objects, nor do they contain objects, they
refer to objects. Object#freeze prevents future changes to the state
of an object, no matter how it is referenced, and it does nothing to
prevent the (re)binding of variables.
And as for warnings vs. errors. IMHO, warnings are just that,
warnings. They warn of something which might be, and sometimes
usually will be a problem, but not always. In most cases, the
response should be to do whatever need be done to eliminate them, but
sometimes they are warnings in the sense of “fasten your seatbelt” or
“slippery when wet.” Redefining a “Constant” can be useful as times.
And some time warnings, like “parenthesize argument(s) for future
version”, turn out to be non-warnings when the envisioned future
version (of the Ruby parser) is abandoned.
–
Rick DeNatale
Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: Rick DeNatale - Developer - IBM | LinkedIn
On Dec 22, 2009, at 12:01 AM, Marnen Laibow-Koser wrote:
well-written code because someone decided that a warning should be
generated.
I hear this quite a bit but have only ever been shown one example I
agree with, based on a new 1.9 warning. Do you have an example you
could share?
James Edward G. II
On Dec 22, 2009, at 12:59 AM, Gary W. wrote:
Really? For what purpose? I can’t think of any instance that you’d
need to change a constant where a variable wouldn’t suffice (but of
course that doesn’t mean it doesn’t exist).I think Rails uses it to reload class definitions. That is to say that a particular constant, such as ArticleController, will refer to different class objects as the class definition changes.
That’s right. This is why you don’t have to constantly restart the
server in development mode.
James Edward G. II
James Edward G. II wrote:
On Dec 22, 2009, at 12:01 AM, Marnen Laibow-Koser wrote:
well-written code because someone decided that a warning should be
generated.I hear this quite a bit but have only ever been shown one example I
agree with, based on a new 1.9 warning. Do you have an example you
could share?
Rick already provided a very good one. I’ll keep an eye out for others.
James Edward G. II
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
On Dec 22, 2009, at 6:59 AM, Rick DeNatale wrote:
And as for warnings vs. errors. IMHO, warnings are just that,
warnings. They warn of something which might be, and sometimes
usually will be a problem, but not always. In most cases, the
response should be to do whatever need be done to eliminate them, but
sometimes they are warnings in the sense of “fasten your seatbelt” or
“slippery when wet.” Redefining a “Constant” can be useful as times.
And some time warnings, like “parenthesize argument(s) for future
version”, turn out to be non-warnings when the envisioned future
version (of the Ruby parser) is abandoned.
The great thing about warnings, in my opinion, is that they sometimes
find bugs for free. That only works though, if you notice the warning.
Thus, you need to keep the noise level down so you can see the warning
when it is given. To me, that means resolving all warnings as they come
up.
It’s interesting to note that what I just described is pretty much
standard operating procedure for Perl programmers now. You’ll be hard
pressed to find modern Perl literature that doesn’t show warnings turned
on and avoided in their code. The same is dramatically less common for
us. This is the one place I feel their culture is superior to ours.
The most important aspect to me is libraries though. If you write a
library that throws warnings, I think we should be able to take your
keyboard away. It’s the whole second-hand smoke thing. You didn’t just
make a bad choice for you but for me too.
It’s also worth noting that it is possible to change a constant without
a warning. In fact, it’s possible to do all of Ruby’s dynamic magic
without warnings, so you certainly can avoid them if you desire.
James Edward G. II
On Dec 22, 2009, at 8:49 AM, Marnen Laibow-Koser wrote:
Rick already provided a very good one.
The only example I can find from Rick in this thread that throws a
warning is constant reassignment. That can be done without a warning:
A = :one
=> :oneA = :two
(irb):2: warning: already initialized constant A
=> :two
Object.send(:remove_const, :A)
=> :twoA = :three
=> :three
Given that it’s pretty easily avoided and it makes it move obvious that
you are trying to do something unusual, I don’t consider that a good
example.
Or were you referring to something else?
James Edward G. II
-----Original Message-----
From: Gary W. [mailto:[email protected]]
On Dec 22, 2009, at 12:59 AM, Walton H. wrote:Really? For what purpose? I can’t think of any instance that you’d
need to change a constant where a variable wouldn’t suffice (but of
course that doesn’t mean it doesn’t exist).I think Rails uses it to reload class definitions. That is to say that
a particular constant, such as ArticleController, will refer to
different class objects as the class definition changes.
Ah, that does make sense. Thank you for the clarification.
James Edward G. II wrote:
On Dec 22, 2009, at 6:59 AM, Rick DeNatale wrote:
And as for warnings vs. errors. IMHO, warnings are just that,
warnings. They warn of something which might be, and sometimes
usually will be a problem, but not always. In most cases, the
response should be to do whatever need be done to eliminate them, but
sometimes they are warnings in the sense of “fasten your seatbelt” or
“slippery when wet.” Redefining a “Constant” can be useful as times.
And some time warnings, like “parenthesize argument(s) for future
version”, turn out to be non-warnings when the envisioned future
version (of the Ruby parser) is abandoned.The great thing about warnings, in my opinion, is that they sometimes
find bugs for free.
I don’t think I’ve ever had this happen in Ruby, since Ruby warnings are
pretty useless. Anyway, that’s what tests are for.
That only works though, if you notice the warning.
Thus, you need to keep the noise level down so you can see the warning
when it is given. To me, that means resolving all warnings as they come
up.
Yes, but don’t make a fetish out of it. If you’re relying on warnings
to find bugs, then you’re not testing enough.
It’s interesting to note that what I just described is pretty much
standard operating procedure for Perl programmers now. You’ll be hard
pressed to find modern Perl literature that doesn’t show warnings turned
on and avoided in their code. The same is dramatically less common for
us. This is the one place I feel their culture is superior to ours.
There are two reasons for this.
The most important aspect to me is libraries though. If you write a
library that throws warnings, I think we should be able to take your
keyboard away. It’s the whole second-hand smoke thing. You didn’t just
make a bad choice for you but for me too.
To me, it looks a little unprofessional, but I’m not going to avoid a
decent library just because it throws warnings. Again: warnings are not
errors!
It’s also worth noting that it is possible to change a constant without
a warning. In fact, it’s possible to do all of Ruby’s dynamic magic
without warnings, so you certainly can avoid them if you desire.
True. But why bother? A warning is not ipso facto a problem.
James Edward G. II
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
Hi,
Am Dienstag, 22. Dez 2009, 23:00:48 +0900 schrieb Sonja Elen K.:
Should I only use symbols for hash keys and method names?
Today, I almost used floats as hash keys. I was really frightened
when I noticed what I was doing.
Bertram
On Dec 22, 2009, at 9:02 AM, Marnen Laibow-Koser wrote:
- Perl warnings are actually useful.
I agree that Perl’s warnings system is superior. I wish we had the
ability to disable specific warnings, as they do.
- Perl programmers don’t tend to test systematically.
Tests are one tool to help you prevent bugs. There are others, like
warnings.
A car has more than one feature that helps keep passengers alive in a
crash and that’s a good thing. There’s nothing wrong with using every
tool at your disposal.
The most important aspect to me is libraries though. If you write a
library that throws warnings, I think we should be able to take your
keyboard away. It’s the whole second-hand smoke thing. You didn’t just
make a bad choice for you but for me too.To me, it looks a little unprofessional, but I’m not going to avoid a
decent library just because it throws warnings.
Boy, I sure will, if I have a choice.
It’s also worth noting that it is possible to change a constant without
a warning. In fact, it’s possible to do all of Ruby’s dynamic magic
without warnings, so you certainly can avoid them if you desire.True. But why bother? A warning is not ipso facto a problem.
Now I can tell that you didn’t really read my message. I gave my
reasons.
You have your techniques for building robust software, I have mine, and
other programmers have theirs. There’s nothing wrong with that of
course.
If code throws warnings, it reduces some of my options. I would rather
avoid that when possible.
James Edward G. II
On 22.12.2009 18:38, Marnen Laibow-Koser wrote:
Right – if the tool is useful. But I think you’re trying to tell me
that the squealing noise that my car makes at speeds over 35 mph is a
safety feature, because it prevents me from driving too fast.
To stay within the metaphor of cars:
If your car makes a squaeling noise in certain circumstances, would you
not go and check if this is a serious problem?
IOW: A warning is just that: a warning. Sometimes it’s something bad
(the squealing noise could be a misaligned fan belt), sometimes it is
not (the fan belt is just wet).
It’s code smell: You do smoething that is possible, but not recommended.
Me, I like neither #remove_const, nor reassignment w/ a warning, but if
has to be the one or the other, throw me a warning that your code is
doing something I do not expect (i.e. that Constants aren’t constant).
How the warning is provided (either by Ruby, or by your code), I don’t
care, as long as I can react accordingly.
James Edward G. II wrote:
On Dec 22, 2009, at 9:02 AM, Marnen Laibow-Koser wrote:
- Perl warnings are actually useful.
I agree that Perl’s warnings system is superior. I wish we had the
ability to disable specific warnings, as they do.
- Perl programmers don’t tend to test systematically.
Tests are one tool to help you prevent bugs. There are others, like
warnings.A car has more than one feature that helps keep passengers alive in a
crash and that’s a good thing. There’s nothing wrong with using every
tool at your disposal.
Right – if the tool is useful. But I think you’re trying to tell me
that the squealing noise that my car makes at speeds over 35 mph is a
safety feature, because it prevents me from driving too fast. 
The most important aspect to me is libraries though. If you write a
library that throws warnings, I think we should be able to take your
keyboard away. It’s the whole second-hand smoke thing. You didn’t just
make a bad choice for you but for me too.To me, it looks a little unprofessional, but I’m not going to avoid a
decent library just because it throws warnings.Boy, I sure will, if I have a choice.
It’s also worth noting that it is possible to change a constant without
a warning. In fact, it’s possible to do all of Ruby’s dynamic magic
without warnings, so you certainly can avoid them if you desire.True. But why bother? A warning is not ipso facto a problem.
Now I can tell that you didn’t really read my message. I gave my
reasons.
I did read your message. Your reasons just seem a little flimsy to me.
You have your techniques for building robust software, I have mine, and
other programmers have theirs. There’s nothing wrong with that of
course.
Of course.
If code throws warnings, it reduces some of my options. I would rather
avoid that when possible.
So would I, when possible. I just don’t think it’s worth a lot of extra
effort.
James Edward G. II
On Dec 22, 2009, at 11:38 AM, Marnen Laibow-Koser wrote:
warnings.
A car has more than one feature that helps keep passengers alive in a
crash and that’s a good thing. There’s nothing wrong with using every
tool at your disposal.Right – if the tool is useful. But I think you’re trying to tell me
that the squealing noise that my car makes at speeds over 35 mph is a
safety feature, because it prevents me from driving too fast.
I was referring to items like seat belts and air bags. 
James Edward G. II
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs