so long as remove_const still would work, I think making reassignment
an exception would be a good idea. This way, you'd need to be
explicit about your decision to change what a constant points to.
-greg
···
On Mon, Dec 21, 2009 at 8:38 PM, Gennady Bystritsky <Gennady.Bystritsky@quest.com> wrote:
So does it mean, it can be changed, but not encouraged?
You may say so. I just did not want to bring it up for simplicity sake. For me any warning produced by my code must be fixed, and in this case the fix would be to check that constants are assigned only once. I personally would prefer an exception for such cases.
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.
* 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.
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).
···
-----Original Message-----
From: James Edward Gray II [mailto:james@graysoftinc.com]
I'm not sure we should go quite THAT far. It is used in the wild for
features people do like.
For me any warning produced by my code must be fixed, and in this case the fix would be to check that constants are assigned only once.
You are a hero. I wish all Ruby library developers could hear your
wisdom.
I don't. There are certain contexts where warnings are generated even
though the code is fine. I'm not going to waste time fixing otherwise
well-written code because someone decided that a warning should be
generated.
Warnings are just that: warnings -- not errors. Sure, 99% of the time
it's better to avoid the warning, but I'm not going to worry too much
about the other 1%.
Best,
···
On Dec 21, 2009, at 7:38 PM, Gennady Bystritsky wrote:
Yes, but you rarely touch that in actual practice. Ruby symbols, OTOH,
are easily manipulated and widely used. They have a much wider range of
applications than Perl symbols.
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.
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 Gray II
···
On Dec 22, 2009, at 9:02 AM, Marnen Laibow-Koser wrote:
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.
Gary Wright
···
On Dec 22, 2009, at 12:59 AM, Walton Hoops wrote:
-----Original Message-----
From: James Edward Gray II [mailto:james@graysoftinc.com]
I'm not sure we should go quite THAT far. It is used in the wild for
features people do like.
There are also ways to do it without a warning.
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 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
···
On Dec 22, 2009, at 12:01 AM, Marnen Laibow-Koser wrote:
James Edward Gray II wrote:
On Dec 21, 2009, at 7:38 PM, Gennady Bystritsky wrote:
For me any warning produced by my code must be fixed, and in this case the fix would be to check that constants are assigned only once.
You are a hero. I wish all Ruby library developers could hear your
wisdom.
I don't. There are certain contexts where warnings are generated even
though the code is fine. I'm not going to waste time fixing otherwise
well-written code because someone decided that a warning should be
generated.
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.
···
On Dec 22, 2009, at 9:02 AM, Marnen Laibow-Koser wrote:
That's right. This is why you don't have to constantly restart the server in development mode.
James Edward Gray II
···
On Dec 22, 2009, at 12:59 AM, Gary Wright wrote:
On Dec 22, 2009, at 12:59 AM, Walton Hoops wrote:
-----Original Message-----
From: James Edward Gray II [mailto:james@graysoftinc.com]
I'm not sure we should go quite THAT far. It is used in the wild for
features people do like.
There are also ways to do it without a warning.
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.
···
-----Original Message-----
From: Gary Wright [mailto:gwtmp01@mac.com]
On Dec 22, 2009, at 12:59 AM, Walton Hoops 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.
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.
···
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.
I was referring to items like seat belts and air bags.
James Edward Gray II
···
On Dec 22, 2009, at 11:38 AM, Marnen Laibow-Koser wrote:
James Edward Gray 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.
