Symbols vs. constants?

[Bertram Scharpf]

Hi,

Am Dienstag, 22. Dez 2009, 21:59:30 +0900 schrieb Rick DeNatale:

=20
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


--=20
Bertram Scharpf
Stuttgart, Deutschland/Germany
*
Discover String#notempty? at <http://raa.ruby-lang.org/project/step>.

 

[Sonja Elen Kisa]

Should I only use symbols for hash keys and method names?

 

[James Edward Gray II]

=20
I don't. There are certain contexts where warnings are generated even=20=

though the code is fine. I'm not going to waste time fixing otherwise=20=

well-written code because someone decided that a warning should be=20
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 Gray II=

 

[James Edward Gray II]

On Dec 22, 2009, at 12:59 AM, Walton Hoops wrote:
=20

-----Original Message-----
From: James Edward Gray II [mailto:[email protected]]
=20
I'm not sure we should go quite THAT far. It is used in the wild = for
features people do like.
=20
There are also ways to do it without a warning.

=20
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).

=20
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 Gray II=

 

[James Edward Gray II]

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 Gray II

 

[Marnen Laibow-Koser]

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 Gray II

Best,

 

[Walton Hoops]

-----Original Message-----

From: Gary Wright [mailto:[email protected]]

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 Gray II]

=20
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:
(irb):2: warning: already initialized constant A
=3D> :two
=3D> :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 Gray II=

 

[Marnen Laibow-Koser]

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.
* Perl warnings are actually useful.
* Perl programmers don't tend to test systematically.

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 Gray II

Best,

 

[Bertram Scharpf]

Hi,

Am Dienstag, 22. Dez 2009, 23:00:48 +0900 schrieb Sonja Elen Kisa:

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

 

[James Edward Gray II]

=20
There are two reasons for this.
* 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.

=20
To me, it looks a little unprofessional, but I'm not going to avoid a=20=

decent library just because it throws warnings.

Boy, I sure will, if I have a choice.

=20
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 Gray II

 

[Marnen Laibow-Koser]

I agree that Perl's warnings system is superior. I wish we had the
ability to disable specific warnings, as they do.


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.

Boy, I sure will, if I have a choice.


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.

 

[Phillip Gawlowski]

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 Gray II]

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 Gray II