Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:106671
MIME-Version: 1.0
References: <CAFPFaML19B_RehrUQLEy_oFae-H5r3+BpUGg=GF1js83cJpJqQ@mail.gmail.com>
 <CAEYWF=4cx_i=3rCfFKeBT0Jq0e4=P0PeY2wd6YEwog_VdA1+Dg@mail.gmail.com>
 <CAJHtznzie34C92y2nTRXxhD99FEW-5hmruVatsrLDHcAKvTccQ@mail.gmail.com>
 <CAEYWF=7S2SxzxU+TzRV0Rc7FNMvyZBkAENVTNbZKqrs71Uyijw@mail.gmail.com>
 <000001d54e5a$02ac09f0$08041dd0$@roze.lv> <2b5588d6-d667-321f-22f1-46a22bb797c5@korulczyk.pl>
 <000001d54ea3$eb3480a0$c19d81e0$@roze.lv> <ad6b9615-372d-69ba-9ca5-e8fa554c5aea@korulczyk.pl>
 <000301d54ead$b43e7b00$1cbb7100$@roze.lv> <59378662-77ca-0779-10cb-c25acf1b45ef@korulczyk.pl>
 <CAKOpQSySEqE4VR+b0Twp4NxZMa+ruEYTbV7qr38Tcw8wqobH2A@mail.gmail.com>
 <CAFPFaMKBWEo-MXCP75vFt2JEvNXzLVhW=f2gGaGHSazb1oXK8Q@mail.gmail.com> <0243f600-f4b6-d6fd-9046-968a6a470e51@gmail.com>
In-Reply-To: <0243f600-f4b6-d6fd-9046-968a6a470e51@gmail.com>
Date: Tue, 20 Aug 2019 19:44:36 +0200
Message-ID: <CAFPFaMJheSOJivx39seyNrRgObviPXpMpY7zLHUwVTu27LMdiw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000087ecc4059090031f"
Subject: Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
From: george.banyard@gmail.com ("G. P. B.")

--00000000000087ecc4059090031f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

2019=E5=B9=B48=E6=9C=8820=E6=97=A5(=E7=81=AB) 16:47 Rowan Tommins <rowan.co=
llins@gmail.com>:

> On 20/08/2019 13:51, G. P. B. wrote:
> >    - I seriously don't appreciate that the RFC has been edited*WITHOUT*
> my
> > knowledge to add endorsement names on the counterargument to the RFC on
> the
> > RFC itself  when the appropriate place would have been the counter
> argument
> > document.
>
>
> While I appreciate that there is a certain implication of "ownership"
> when you are the author of an RFC, it is ultimately a resource for the
> community as a whole to understand the discussion, which is why the
> guide at https://wiki.php.net/rfc/howto explicitly mentions including
> both positive and negative feedback.
>
> The only problem I can see with other people editing "your" RFC is if
> later readers could mistake the edits for your own opinion; even if the
> whole counter-argument had been a section rather than a separate page,
> it would be clear that readers shouldn't do that. In this case, the only
> edits are to add a list of names, which is basically what the voting
> widget does anyway, so I really can't see any reason to be upset about it=
.
>
> Regards,
>
> --
> Rowan Tommins (n=C3=A9 Collins)
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Citation:

> Note: An RFC is effectively =E2=80=9Cowned=E2=80=9D by the person that cr=
eated it. If you
> want to make changes, get permission from the creator.


Taken from: https://wiki.php.net/rfc

I'm upset that a voting document is edited without my knowledge, and I
don't see why I haven't been asked (probably because I would have said no
to the edits)


On Tue, 20 Aug 2019 at 17:18, Sara Golemon <pollita@php.net> wrote:

> This has been a topic of discussion in the past. The agreement was that
> non-author edits are permitted if they are isolated to a clear
> "counter-arguments" section.  If someone had changed the meaning of the R=
FC
> or of your arguments in favor of it that would be another story, but that=
's
> not what happened here.
>
> -Sara
>

Gotcha so from now on I'll just add a sentence "George Peter Banyard
supports this RFC" every time I'm in agreement with an RFC to the RFC
because having your name tied to a vote is apparently irrelevant, because
this is exactly what you did (but only on the RFC not the counter argument
page).


On Tue, 20 Aug 2019 at 18:02, Chase Peeler <chasepeeler@gmail.com> wrote:

> > I think that now we need to fix the documentations out there. short
> > tags will stay in PHP for at least another 10+ years, so maybe we
> > should simply consider them not a part of legacy but a special kind of
> > a feature. There are some parts in PHP comments and docs that needs
> > this fixed and sorted out better a bit (probably - specially in the
> > ini files itself etc).
> >
> > I think we should still discourage their use. We should be explicit in
> the
> documentation that code which uses short tags might not be portable. Just
> because they exist, doesn't mean we should suddenly change our treatment =
of
> them when it comes to best practices. If there is any documentation that
> doesn't make this clear, submit a bug report.


The document has been discouraging their use for god knows how long.

> PHP also allows for short open tag *<?* (which is discouraged since it is
> only available if enabled using the short_open_tag
> <https://www.php.net/manual/en/ini.core.php#ini.short-open-tag> php.ini
> configuration file directive, or if PHP was configured with the
> *--enable-short-tags* option).
>

See: https://www.php.net/manual/en/language.basic-syntax.phptags.php

On a final note, I don't think I have anything more to add to this topic so
I probably won't respond to subsequent messages in this thread.

Best regards

George Peter Banyard

--00000000000087ecc4059090031f--