It really should have support for having class modifications scoped to your module (and accessible manually from outside), but I couldn't find it.
If the language is such that everything "should" be a method on the broadest-possible class, people are going to monkeypatch, because it feels "wrong" otherwise. People just want to write idiomatic code.
In Objective-C this ends up not being an issue, because there's very little usage of non-Apple libraries -- plus the default way of adding methods doesn't allow replacement, and Apple libraries are well-versioned (if you build your app for >10.4, API changes in 10.5 are invisible).
Scoped mixins. Basically, you can modify
object behavior within a scope. So changes
to core classes can be localized.
++ INCOMPLETE ++A story about how a web app was broken by installing the Classifier gem due to an Array#sum conflict wouldn't be a story. You change your web app and move along smartly. But who in tarnation is up for patching gems to deal with the conflicts caused by gems patching Array on each other. Ugh.
if hash[:a][:long][:key][:chain].is_a?(SafeNestedHash::UndefinedHash)
if hash[:a][:long][:key][:chain].nil?
What are you testing for here? To see if the hash is empty or something? What makes an "UndefinedHash" undefined? If it IS defined, then it should be assumed to be the type of object you are looking for until the code tries to do something that breaks on a non-supported type.
In essence, the problem could be "solved" by monkey patching nil, though that would be the worst sort of abuse of monkey patching I can imagine. As far as checking the class is concerned, well that's just a convenient method of showing what I'm doing, I could also define a method such as is_not_defined? and check if the object at the end of the hash responds to that. The fundamental issue is that any object could be stored in the hash, so whatever I check has to be valid for any possible object. That's why I defined nil? for the UndefinedHash class even though it is a bit kludgey--it's better than monkey patching Object or NilClass.
So, why not just let it throw an error? The interpreter is expecting one thing and gets another -- that's a type error right there. Why bother with anything else?
(ie. looking up a hash key will create an empty hash there even without an assignment)
That's pretty silly ;)
Say there is an algorithm you want to run where you are grouping things into a deeply nested set of categories. A nested hash referencing arrays is a good data structure for this. In PHP this is trivial (though not terribly efficient). In Ruby you have to deal with maintaining the hash. There are many ways to do it, but my SafeNestedHash class lets you do it with a concise, natural syntax. Perhaps if you have an aversion to using a library for this then you would define a pair of methods like key_exists?(hash, key_chain) and set_key(hash, key_chain). You could also monkey-patch hash to have those methods. You could also encapsulate the logic into an object that handles all the logic. Or (as you seem to suggest) you could let the interpreter throw an exception and then handle it with rescue, which IMO would be just a notch behind monkey-patching in terms of bad practice since exceptions should be for unexpected circumstances. I just happened to go with creating a class that abstracts this all away. Yes there is a bit of leakiness, but there is no monkey patching, and any other solution would require either ballooning the actual function with incidental accounting details, or else utilizing some other abstraction which would need to be used with the same understanding of its purpose, at which point it's just a matter of taste.
def wtf(l, count=0):
cl = l[0]
try:
return wtf(cl[count:], count+1)
except IndexError:
# Reverse the list and start over
cl = l[::-1]
return wtf(cl, 0)
I know you can do useful things with Exceptions when necessary. However I have to say unequivocably that using an exception in this case would be the worst possible idea. Why? Because the exception would be NoMethodError (ie. from nil[:key]). This equivalent to a NullException in Java, indicating all manner of generic logic errors that could have occurred anywhere within the stack.
If you looked at what I was actually doing, you might agree that SafeNestedHash is an incredibly useful abstraction. Hell, if it was written in PHP you could look at the algorithm and say, "wow, that's fast, elegant and readable." I'm not sure why you're so dead set that I'm doing something wrong, but you're just pulling this stuff out of thin air without any context.
Yay weak typing! cough
It's true that Ruby should provide better tools. But it's also true that a lot of what goes on is avoidable and there's nothing wrong with you pointing that out.
Alright, so why the "(you) publicly blame and shame others for the mess" then?
I am not sure if I am reading this right, but there seems to be abit of a moralizing tone there. "The difference between us is you [ do something slightly slimy] , I [ do something very noble]".
At least that's the way it reads to me.
I am not sure in a discussion of a technical issue there is much of a difference in practice. Why is "this is sucky" not acceptable unless one has spent significant time trying to clean it up?
Edit : Retracted after reading "Actually, I was just trying to pretend that I'm a kindly old wise man that everybody likes for his civic-minded attention to duty. In reality, I'm just as disgusted as you are and the post title says it all.".
I thought I'll leave it up here as a warning not others not to read too much into something.
Which is why good Rubyists use these tools sparingly and sensibly. It is not "standard operating procedure."
Programmers of any language can misuse the tools made available. Tarring the language with the brush of its poorest users is disingenuous.