On Thu, Mar 08, 2007 at 09:05:32AM +0000, Smylers wrote: : So I fear that people will do the same thing in Perl 6. Which, : initially, will appear to work. But then, some months later, somebody : upgrades the installed version of a module (or the program gets deployed : on another computer, which happens to have a more recent version : installed), and suddenly the program will break.
Nope, check your assumptions, you've got a big one that just ain't so. Perl 6 is specced to keep all the old versions of modules around in the library (unless the new version claims to emulate the old version). So an upgrade doesn't generally break fixed dependencies. : In summary, I feel uneasy about the combination of: : : * In many (most?) cases the breakage will be arbitrary, in that the : module would've worked fine had it been allowed to run rather than : being stopped by the version-checker. It is allowed to run anyway, and it runs with a known good version. If there's arbitrary breakage, it's because dependencies depend on a different version that is incompatible with your version because of some exclusive resource. Modules that manage an exclusive resource (such as a database handle) need to learn to deal with that, either by emulating older versions, or finding some way to share the resource between different versions. : * It's a change from what was good practice in Perl 5. s/good/common/; First of all, Perl 6 is not aimed at exactly the same problem space as Perl 5. Hopefully the new Perl problem space is a superset of the old one...except perhaps for using formats to print reports on your line printer. :-) Second, what is "good" practice in Perl 5 is often just a workaround for one or another of the design flaws; these underlying design flaws are the real reason Perl 5 has been becoming stagnant over the last decade or so. This has been happening since long before Perl 6 was thought of. Those who believe the stagnation of Perl 5 is caused by Perl 6 should go back and reread the 361 RFCs, and then recognize that it's very difficult to fix Perl 5 in a piecemeal fashion without simply make it a bigger mess than it already is. We're trying very hard to make different mistakes this time, and I believe we're succeeding. :-) : * The bug _cannot_ hurt straight away, only at some point in the future : (and often by actions of somebody who isn't the programmer). Only if the module writers are stupid about preserving the semantics of exclusive resources. If there are no exclusive resources it doesn't matter if two different versions of the same module are loaded--neglecting memory considerations, which I believe is well worth neglecting for the benefit. And the benefit of this approach is that it's much more scalable to programming in the large when various of your dependencies can depend on different versions of the same module without forcing upgrades on modules that don't need it. On top of which, you can get the old semantics if you want, but we just rehuffmanized it so it's not the default unless you leave off the version requirement entirely. We also provide good intermediate huffmanizations that allow you to follow a maintenence track without automatically leaping to the next bleadtrack, using 6.2.* notation. How do you do that in Perl 5? Larry
