Front page | perl.perl5.porters |
Postings from July 2016
Re: Indented here docs?
Thread Previous
|
Thread Next
From:
Father Chrysostomos
Date:
July 5, 2016 05:10
Subject:
Re: Indented here docs?
Message ID:
20160705051011.13624.qmail@lists-nntp.develooper.com
Sawyer X wrote:
> On 07/03/2016 01:12 AM, Father Chrysostomos wrote:
> > Sawyer X wrote:
> >> Perhaps we should consider a change to the policy
> >> Thoughts?
> > It should not be necessary. We are not automatons who cannot make
> > exceptions here and there. :-)
>
>
> Those two sentences pointed at different intentions in my head. Are you
> saying you aren't against making an exception for this or you still
> suggest abiding by the policy? Not nitpicking, I just want to make sure
> I understand. :)
I am not opposed to making an exception. In fact, I am ambivalent
about whether we just go ahead and add the feature as we did <<>>
(making the implementor's life easier), or whether we modify the pol-
icy to allow a shorter experiment, or whether we just make an excep-
tion regardless of the policy, etc.
I do think having a policy that spells everything out in fine detail
is overkill (it results in silly conversations like this), but that is
not my call.
Basically, you should understand my musings as not making any particu-
lar stand, but, rather, as reminders of things that need to be taken
into consideration. In fact, let me continue. I would suggest that
you consider:
1. Whether it is likely that we will rescind the new here-doc syntax.
2. Whether it is likely that we will want to change its behaviour.
3. Whether it is likely that we will run into implementation problems
that render it forever buggy and unfixable. (I worried about that
with lexical subs; I think I still do a bit.)
Since I know the code well, I can tell you we are safe with
regard to 3.
And then I hope you will make a wise decision based on those
factors. :-)
> > Also, there is something related that I have been thinking about
> > lately. Once a feature is no longer experimental in blead, there is
> > no reason for people not to go ahead and use it in earlier versions
> > where it is officially experimental (unless we think it may revert to
> > experimental status in blead, which seems unlikely to me), as long as
> > we document just how far back the feature is stable, both in terms of
> > behaviour and in terms of not crashing. (E.g., we should document
> > that lexical subs are likely to crash before 5.22.)
> >
> > This seems obvious to me, but there are those who are afraid of the
> > experimental label and will stay away from it. How do we communi-
> > cate that a feature accepted in, say, 5.26 is usable in 5.22? Do
> > we need to?
>
> If we abide by the policy, this means that you only receive one version
> in which we *know* it works (since it requires to be unchanged
> behaviorally for a entire release before we take it off "experimental"
> label). So whatever version in which it fully became "stable", it can
> only be one release of unchanged behavior. Yes?
Yes.
> The only situation in which it might be more relevant is if we have any
> experimental feature that isn't set to stable for more than one version.
> We have a few, but it's relatively rare nowadays, no?
I am not sure what you mean.
What I am trying to say is that, if you want the <<~- feature in 5.28,
you will already effectively get it if we make it non-experimental in
5.29.0, because then you know it will be safe to use in 5.28 and you
can upgrade without it breaking your code. (But we could rescind the
acceptance of a feature within a blead cycle, so maybe everything I
have said is nonsense.)
This conversation is fun. I only understand half of what you say.
You only understand half of what I say. :-)
BTW, you might be interested to know that <<>>, which was added
unexperimentally, broke an existing use of bare <<. Also, the new
syntax error message for <<<<<< also broke an existing use of bare <<.
Personally, I think that is fine. I also do not see it necessary to
remove the deprecated << syntax and make it die in those cases where
it does not conflict with new syntax. (I have a selfish reason: I do
not want ot go searching through all my code for the numerous places
where I used << with a semicolon right after it. Piecemeal removal of
deprecated features is kinder.)
Thread Previous
|
Thread Next