2 ms·

In the micro, this is definitely a useful crutch for using badly-written/badly-behaved code. (In the example, it usefully provides a way to maintain sanity whe

In the micro, this is definitely a useful crutch for using badly-written/badly-behaved code. (In the example, it usefully provides a way to maintain sanity when `app1.rb` and `app2.rb` both define a global constant named `PORT`) However, I'm not sure how much existing code is defining stuff in such a poorly considered way. (I don't mean that rhetorically. Maybe it's more pervasive than I think) Furthermore, would adding this feature to the language actually encourage such bad behavior? (Would it even be "bad" behavior at that point?) So I'm kind of leaning toward "I can see how this would be useful, but I don't want the language to condone such a bad practice."

hartator 1y ago
Yeah, and it kind of defeat passing PORT as a global variable. Like you might expect PORT=2917 to do effect these apps ports.
- JohnBooty 1y ago
  I'd call that some pretty bad behavior; behavior that I'd like to... if not dissuade, at least not encourage.
tinco 1y ago
I can rest your mind, I've being coding Ruby for 17 years now, and I've never seen two gems or even files define the same global constant in a way that wasn't intentional. It's fair to say it's not at all pervasive. That said, I do think there's use to this. First of all it would allow fancy platforms like RoR to make more effective use of namespaces. Right now you always need to specify the fully qualified name of a constant whenever you're defining it, which is just not aesthetically pleasing. Another potentially useful place for this is in migrations. If you could just move the old implementation of a thing into a subdirectory and then load it into a namespace you make references to it a lot more explicit, and you give the replacement architecture full freedom within its root namespace. Just to say, it's not only bad behavior that would be enabled by this feature. I definitely agree that having gems not sticking to their own modules would be a very bad thing indeed.

hartator 1y ago

Yeah, and it kind of defeat passing PORT as a global variable. Like you might expect PORT=2917 to do effect these apps ports.

JohnBooty 1y ago
I'd call that some pretty bad behavior; behavior that I'd like to... if not dissuade, at least not encourage.

tinco 1y ago

I can rest your mind, I've being coding Ruby for 17 years now, and I've never seen two gems or even files define the same global constant in a way that wasn't intentional. It's fair to say it's not at all pervasive. That said, I do think there's use to this. First of all it would allow fancy platforms like RoR to make more effective use of namespaces. Right now you always need to specify the fully qualified name of a constant whenever you're defining it, which is just not aesthetically pleasing. Another potentially useful place for this is in migrations. If you could just move the old implementation of a thing into a subdirectory and then load it into a namespace you make references to it a lot more explicit, and you give the replacement architecture full freedom within its root namespace. Just to say, it's not only bad behavior that would be enabled by this feature. I definitely agree that having gems not sticking to their own modules would be a very bad thing indeed.