On Thu, Jul 05, 2012 at 02:39:00PM +0200, Moritz Lenz wrote: > Am 05.07.2012 07:11, schrieb Patrick R. Michaud:
> > 3. Str.bytes > > > > The C<.bytes> method on C<Str> has always been somewhat problematic; in > > Perl 6 > > we typically think of strings in terms of characters, codepoints, graphemes, > > or units other than bytes. The C<.bytes> method really makes more sense for > > something like C<Buf>, but not C<Str>. Thus it was decided to remove > > C<.bytes> > > completely from the C<Str> specification. > > > > How long should Rakudo keep Str.bytes available for programs that may be > > using it? > > Since .bytes isn't used very often, and it's easy to grep for and easy > to replace (with .encode.bytes), I'd simply announce it one release > announcement, and remove it after the release. > > > How do we let people know that it's going away, and what to > > potentially use instead? > > Add a small note about the change in the compiler and star announcement, > and keep some document around (maybe in a wiki?) that has details on how > to do the upgrade. > > > (For Str.bytes, I've introduced an experimental "is DEPRECATED" trait > > into Rakudo, thus Str.bytes is actually marked as "DEPRECATED" in the > > source. We could potentially extend this trait so that an option or > > pragma causes any uses of DEPRECATED routines to generate warnings > > or exceptions.) > > +1 The experience of how Perl 5 is now trying to do things is based on various experiences and observations, including how Rakudo tripped up over Parrot changes. Documentation doesn't work. Parrot documented that various features were deprecated, and then removed them. As best I cam remember, more than once Rakudo didn't even realise that it was using them, and didn't find out until it broke because the feature had been removed. Likewise Perl 5 code on CPAN has been using features deprecated for over 10 years. More insidiously, Perl 5 code on CPAN has pre-requisites which use deprecated features, but doesn't realise that it is. People only really pay attention to deprecated features if using them generates warnings. (Code still runs, but it warns. That's what warnings are *supposed* to be. But then QA turns somewhat into the cult of QA, because modules like Test::NoWarnings (and Test::Pod) make any new *warning* fatal, even when that wasn't the intent). And the Perl 5 policy is now that deprecation warnings are on by default (*yes*, you can disable them, that's also the point) because sadly it seems to be the only way to actually inform end users that somewhere in the call stack of code they inherited but never look at, there is now something they need to pay attention to. Nicholas Clark PS Code on CPAN *still* breaks, even with this, because it has blocks with no warnings; with the intent of suppressing just the one known expected warning, but the big hammer happens to take out the (new) deprecation warning too. But this is much less of a problem.
