Front page | perl.perl5.porters |
Postings from March 2001
> > When both the M::BI and M::BF really are available are true drop-in
> > replacements, that is, backward compatibility with the pure-Perl
> > add-ons has been checked,
>
> This will not be 100% backward compatible, since it fixes bugs and corrects
> (serious) mistakes the old code had. But I have essential taken over the
Well, not *that* compatible :-)
> Why? Seeing that the CHANGES files alone are 2.4 MB, why are 46 KByte
> code/documentation (over 13 old) a problem? ;)
>
> I mean, the old version is broken. Fixing it is more important than size or
> did I misunderstand you here?
Point taken. But it's not so much about comparing new candidates
against already existing parts in size than having to choose among
several candidate modules for inclusion, and their usefulness/size
ratio. Also, what goes in cannot be taken out. Ever. Therefore
I tend to favor stable (no jokes about my signature quote, please)
modules (Inline was an exception since it looked, and still looks,
so ingenious an idea -- but the author of Inline quite wisely chose
not to accept my "invitation".)
> > Bignums, especially bigints, are nice to have,
> > but essential, so one must weight the costs carefully.
> ^-- a not missing?
Yes.
> That is what was proposed here:
>
> http://archive.develooper.com/perl6-internals@perl.org/msg02640.html
> [snip]
> There is only one problem: It seems Dan likes to completely rewrite the
> transparent bignum support in C (unlikely that someone will have the time
I'm sorry to sound blunt that discussion about perl 6 internals is
best to have in the perl6-internals mailing list. There's a reason
we decided to start the Perl 6 project, after all... many of the
solutions that will make sense for p6 won't make sense for p5,
and vice versa.
--
$jhi++; # http://www.iki.fi/jhi/
# There is this special biologist word we use for 'stable'.
# It is 'dead'. -- Jack Cohen
Thread Previous
|
Thread Next