4 ms·

Why are you trolling Ruby for this? There are safe ways to metaprogram Ruby very successfully in an extensible and readable fashion. That's why there's a move

Why are you trolling Ruby for this? There are safe ways to metaprogram Ruby very successfully in an extensible and readable fashion. That's why there's a movement in the Ruby community to kill alias_method_chain for one. Nor is this a problem that scales with community size. There are bad programmers everywhere. If using their libraries causes your project to explode, don't use their code. Rails is fully admitted to be too clever for it's own good, which is why the push to Rails3 and cleaning out the kludges in the Rails code base is so important. That's why the Merb project was getting so much attention in the first place. Never the less, this is still about getting numerous different packages to work together. It's a package dependency problem. Granted Ruby's ability to reopen classes anywhere it likes makes this problem more difficult, but i hardly see this as an indictment of any use of the language. So yes, package management is hard. People should metaprogram responsibly. But that's true in other languages as well. :p

raganwald 18y ago
> It's a package dependency problem. If you solve the package dependency problem, you will be left with the meta-programming collision problem. However, I feel that if you solve the meta-programming collision problem, you will also solve the package dependency problem. Which is the point of this post. I am not saying anything about the size or severity of the two problems, just noting that I think solving one will solve the other.
- knowtheory 18y ago
  Raganwald, i agree with your identification of this problem. But the anti-Ruby trolling is getting out of control :( (and i don't blame you for that). There are a couple different suggestions people have discussed, but some of them, like selector namespacing, have been languishing in discussion land for years (Matz has been talking about it for a while apparently). This still doesn't solve the case where you have two different plugins or gems that you'd like to use, that require different versions of the same gem. Ruby is open enough to give you enough rope to hang yourself w/ in this case. The alternative is what... just not doing package versioning? That seems like a step backwards too.
  - raganwald 18y ago
    > The alternative is what... just not doing package versioning? That seems like a step backwards too. Imagine that you have lexical scope for changes to global constants. Like Perl's local keyword or Lisp's let. So you can redefine Array and the new definition is only valid within the lexical scope of a block. Code that the block calls does NOT get the new definition, so your code can have one version of Array#sum, my code can have another, and we can freely call each other or call code that doesn't expect Array to have a #sum method. Now thinking about that solution to the meta-programming collision problem, the solution to the gem version problem is also plain: gems can be scoped too, and if I use version 1 of a gem in a block and you use version 2 in a block, only the code within our blocks see the effects of the gems they include. So yes, packages have versions, but the same mechanism that applies lexical scope to meta-programming mediates package version conflicts.
- jerf 18y ago
  All of my serious objections to monkeypatching go away if you can scope them. Then I'm just left with a general "that's icky" feeling that I wouldn't press on anyone. Raganwald, have you ever used Perl's "local" keyword? It's really similar to what you're looking for; "in this scope and anything I call, the value of the thing identified by $x is now this; when this scope expires, it goes back to what it was before". For what you're looking for, you'd want to drop the "and anything I call" bit, but it's doable. And I agree that you would also go along ways towards solving this sort of dependency problem.
jerf 18y ago
"Nor is this a problem that scales with community size." - The more people you have writing libraries, the more monkeypatches are made in a library, the more likely it is that the monkeypatches will collide. That's so obvious I don't even know how to argue for it. "Granted Ruby's ability to reopen classes anywhere it likes makes this problem more difficult, but i hardly see this as an indictment of any use of the language." I do, because other languages manage to provide features and libraries without causing this problem. A problem that is unique to the monkeypatching languages (also Javascript) can be laid at the feet of the design decision to permit it and the community decision to roll in it. If the community is indeed walking away from monkeypatching.... that doesn't prove I'm wrong, it proves I am and was right about the dangers involved. I don't feel inclined to give the community much credit for coming around to the realization that unfettered monkeypatching is a bad idea two years later than I did. If you like monkeypatching, you should be listening to Raganwald. He's looking for a way to reap the benefits without paying the price, and I think such a thing could be constructed. Version control is a separate problem indeed. It should be pointed out that I was responding not directly to the original topic, but the posts that are the parent in this chain. This is perfectly valid. Oh, and stuff it with the trolling accusation. I'm not looking for flaming responses, I'm hoping to safe someone from stepping into the monkeypatching tarpit that at least historically the Ruby community has advocated so hard for people to leap into. Again, if the community is walking away from that tarpit too, are they "trolling" when they do that? Trolling means something, and it isn't "having strong opinions with reasons given".
- aaronblohowiak 18y ago
  This is not a monkeypatching problem, per se. It is a problem of scope-independent class definition. There are languages wherin you can monkeypatch the class definition (or the definition of a single instantiation of a class) wherin those patches only are in effect in certain contexts.. so you have a scope to your monkeypatching. I think that this would allow for Interesting Things, while being "safe".
  - catch23 18y ago
    Sometimes monkey patching is good actually. I use Soap4r all the time, and I preferred the debug xml to appear in the console rather than created as a separate file, it was really easy to make a monkey patch that fixed this, without modifying the actual distribution... that way other projects wouldn't be affected. Another time, there was a small bug in Hpricot, rather than fix it directly in source, I patched it in my code, and removed the patch when the fix was in the production stream. At least it's nice to have that option available...

raganwald 18y ago

> It's a package dependency problem. If you solve the package dependency problem, you will be left with the meta-programming collision problem. However, I feel that if you solve the meta-programming collision problem, you will also solve the package dependency problem. Which is the point of this post. I am not saying anything about the size or severity of the two problems, just noting that I think solving one will solve the other.

knowtheory 18y ago
Raganwald, i agree with your identification of this problem. But the anti-Ruby trolling is getting out of control :( (and i don't blame you for that). There are a couple different suggestions people have discussed, but some of them, like selector namespacing, have been languishing in discussion land for years (Matz has been talking about it for a while apparently). This still doesn't solve the case where you have two different plugins or gems that you'd like to use, that require different versions of the same gem. Ruby is open enough to give you enough rope to hang yourself w/ in this case. The alternative is what... just not doing package versioning? That seems like a step backwards too.
- raganwald 18y ago
  > The alternative is what... just not doing package versioning? That seems like a step backwards too. Imagine that you have lexical scope for changes to global constants. Like Perl's local keyword or Lisp's let. So you can redefine Array and the new definition is only valid within the lexical scope of a block. Code that the block calls does NOT get the new definition, so your code can have one version of Array#sum, my code can have another, and we can freely call each other or call code that doesn't expect Array to have a #sum method. Now thinking about that solution to the meta-programming collision problem, the solution to the gem version problem is also plain: gems can be scoped too, and if I use version 1 of a gem in a block and you use version 2 in a block, only the code within our blocks see the effects of the gems they include. So yes, packages have versions, but the same mechanism that applies lexical scope to meta-programming mediates package version conflicts.
jerf 18y ago
All of my serious objections to monkeypatching go away if you can scope them. Then I'm just left with a general "that's icky" feeling that I wouldn't press on anyone. Raganwald, have you ever used Perl's "local" keyword? It's really similar to what you're looking for; "in this scope and anything I call, the value of the thing identified by $x is now this; when this scope expires, it goes back to what it was before". For what you're looking for, you'd want to drop the "and anything I call" bit, but it's doable. And I agree that you would also go along ways towards solving this sort of dependency problem.

jerf 18y ago

"Nor is this a problem that scales with community size." - The more people you have writing libraries, the more monkeypatches are made in a library, the more likely it is that the monkeypatches will collide. That's so obvious I don't even know how to argue for it. "Granted Ruby's ability to reopen classes anywhere it likes makes this problem more difficult, but i hardly see this as an indictment of any use of the language." I do, because other languages manage to provide features and libraries without causing this problem. A problem that is unique to the monkeypatching languages (also Javascript) can be laid at the feet of the design decision to permit it and the community decision to roll in it. If the community is indeed walking away from monkeypatching.... that doesn't prove I'm wrong, it proves I am and was right about the dangers involved. I don't feel inclined to give the community much credit for coming around to the realization that unfettered monkeypatching is a bad idea two years later than I did. If you like monkeypatching, you should be listening to Raganwald. He's looking for a way to reap the benefits without paying the price, and I think such a thing could be constructed. Version control is a separate problem indeed. It should be pointed out that I was responding not directly to the original topic, but the posts that are the parent in this chain. This is perfectly valid. Oh, and stuff it with the trolling accusation. I'm not looking for flaming responses, I'm hoping to safe someone from stepping into the monkeypatching tarpit that at least historically the Ruby community has advocated so hard for people to leap into. Again, if the community is walking away from that tarpit too, are they "trolling" when they do that? Trolling means something, and it isn't "having strong opinions with reasons given".

aaronblohowiak 18y ago
This is not a monkeypatching problem, per se. It is a problem of scope-independent class definition. There are languages wherin you can monkeypatch the class definition (or the definition of a single instantiation of a class) wherin those patches only are in effect in certain contexts.. so you have a scope to your monkeypatching. I think that this would allow for Interesting Things, while being "safe".
- catch23 18y ago
  Sometimes monkey patching is good actually. I use Soap4r all the time, and I preferred the debug xml to appear in the console rather than created as a separate file, it was really easy to make a monkey patch that fixed this, without modifying the actual distribution... that way other projects wouldn't be affected. Another time, there was a small bug in Hpricot, rather than fix it directly in source, I patched it in my code, and removed the patch when the fix was in the production stream. At least it's nice to have that option available...