Front page | perl.perl5.porters |
Postings from December 2017
On Sat, Dec 30 2017, Tomasz Konojacki jotted:
> On Sat, 30 Dec 2017 23:43:36 +0100
> avarab@gmail.com (Ævar Arnfjörð Bjarmason) wrote:
>
>> I'm not ignoring that, but I think my point still stands.
>>
>> If we're going to play language police with perlpolicy.pod there's no
>> *explicit* mention of something that was previously a non-experimental
>> feature becoming experimental, so by that definition we can never change
>> given/when.
>>
>> However, immediately after defining what "experimental" means it talks
>> about how "deprecated" features may be removed in just two release
>> cycles.
>>
>> That's talking about removing a feature of perl that's never been
>> experimental, and has been there since 1987.
>>
>
> You're right although there's a one problem. We almost never remove
> widely used features.
>
> I can think of two notable exceptions, defined(@foo) and . in @INC.
> However, there's a one, extremely important difference between those
> features and smartmach/given/when: they were easily replaceable.
>
> All you had to do to fix code using defined(@foo) was remove defined().
>
> All you had to do to fix code relying on '.' in @INC was add "use lib '.'"
> at the beginning of the script.
>
> With new smartmatch the situation is completely different. How would you
> fix $foo ~~ $bar? is it $foo ~~ any(stringwise($bar))? or maybe $bar is
> a regexp? Maybe it can be both?
>
> And that's our real problem. Old smartmatch and given/when have no real
> replacement. That's why we have to rethink everything from the beginning.
Okey, then we patch perlpolicy.pod to say:
diff --git a/pod/perlpolicy.pod b/pod/perlpolicy.pod
index 6c57238eac..dfcf0432f6 100644
--- a/pod/perlpolicy.pod
+++ b/pod/perlpolicy.pod
@@ -248,6 +248,12 @@ no longer ship with Perl, but will continue to be available on CPAN.
=back
+=head1 CAVEATS
+
+Oh and by they way, if something's sufficiently complex or widely
+used, forget about everything we mentioned about
+experimental/deprecated/etc. above, it's staying, B<forever>.
+
=head1 MAINTENANCE BRANCHES
New releases of maintenance branches should only contain changes that fall into
Which, to be clear, is I'm not taking a particular stance on these
given/when changes, but saying that we should decide, in general, how
the policy applies to changing such long-standing features.
Maybe the answer should be "it doesn't change", or maybe the answer
should be "suck it, take Zefram's patches", regardless of what any of us
think about those patches this discussion points to the fact that we
need to patch perlpolicy.pod to describe these situations more
generally.
How are we going to handle the next new feature that gets introduced in
5.30, gets marked as experimental in 5.40, and someone wants to change
in 5.48?
Thread Previous
|
Thread Next