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.


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?


Reply via email to