20 ms·

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 a

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.