Re: [PHP-DEV] RFC: var_export - short syntax for array

[Влад Макин]

Thanks for the feedback!  I will back with improved version of RFC.

вт, 20 авг. 2019 г., 23:01 Sara Golemon :

> On Tue, Aug 20, 2019 at 1:05 PM Влад Макин  wrote:
>
>> I would like to propose a little change in var_export function behavior.
>> For today, this function returns string representation of array in old
>> style with “array” keyword:
>>
>> var_export([]); // array()
>>
>> I think it would be better if the function returned array representation
>> in
>> modern square brackets syntax:
>>
>> var_export([]); // []
>>
>> I do like the idea of doing this, and would even be generally okay with
> just making always work that way since the introduction of square bracket
> syntax is really *quite* old.
>
> The only people I could see being bothered by the change in output would
> be automated code-generation suddenly seeing a (potentially quite massive)
> diff as the bracket style changes.  As an example,
> https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
> line var_export() generated list.  I'm actually /not/ bothered by the idea
> of having a big point-in-time flip of that structure, though I'd want to
> make sure all RMs switch versions at the same time, otherwise it could get
> noisy.
>
> Perhaps an option to quell any dissent might be to add a third param
> $options to allow controlling this behavior.
>
> function var_export(mixed $data, bool $return = false, int $options = 0):
> string {}
>
> And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
> whatever you want to call the constants depending on which behavior you'd
> make default (and honestly, I think we'd make the existing format default).
>
> -Sara
>

Re: [PHP-DEV] Re: PHP 7.4.0beta2 is available for testing

[Jan Ehrhardt]

Sara Golemon in php.internals (Tue, 20 Aug 2019 15:03:07 -0500):
>On Tue, Aug 20, 2019 at 1:58 PM Jan Ehrhardt  wrote:
>
>> Derick Rethans in php.internals (Thu, 8 Aug 2019 09:53:28 +0100 (BST)):
>> >PHP 7.4.0beta2 has just been released and can be downloaded from:
>>
>> Was 7.4.0beta3 skipped? 7.4.0beta4 is now tagged at Github.
>> https://github.com/php/php-src/releases/tag/php-7.4.0beta4
>
>Yes. Counting is hard. Also, skipping version numbers is a proud PHP
>tradition now.  RMs discussed it and we're just gonna roll with it.  There
>are plenty more digits in the computer.

Be glad that Derick's typo was at the end of the version string.
Otherwise we would have had 6.4.0beta3 now ;-)
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 23:37, Rowan Tommins  wrote:
>
> On 20/08/2019 22:18, Peter Kokot wrote:
> >> The approach was: add the deprecation notice in PHP 8, and remove short 
> >> open tags in PHP 9 or PHP 10 (purposely left vague to get more support for 
> >> the idea - as getting the deprecation underway is the most important move).
> >>
> > I guess we should really highlight also
> > such option and discuss this more rationally back then. Now, we have
> > postponed this until who knows when and also without any clear
> > guideline for what will happen with short tags if they will be ever
> > removed or not...
>
>
> I honestly don't think it would make any difference to most people who
> voted against. The counter-arguments people have presented, again and
> again, are not about the pace of removal, but about whether removal is
> needed at all. If anyone wants to revive this proposal in future, it is
> that counter-argument that they would need to understand and address.
>
> Regards,

I think so too, yes. We will have the same discussion... I'll leave it
be. I just have my own opinion about them. Facts are facts (what
software does and allows to do) and what documentation and code
comments say (something completely different). What is programmer
advised to do is not the same as what can programmer do with the
language. That's all.

-- 
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 22:18, Peter Kokot wrote:

The approach was: add the deprecation notice in PHP 8, and remove short open 
tags in PHP 9 or PHP 10 (purposely left vague to get more support for the idea 
- as getting the deprecation underway is the most important move).


I guess we should really highlight also
such option and discuss this more rationally back then. Now, we have
postponed this until who knows when and also without any clear
guideline for what will happen with short tags if they will be ever
removed or not...



I honestly don't think it would make any difference to most people who 
voted against. The counter-arguments people have presented, again and 
again, are not about the pace of removal, but about whether removal is 
needed at all. If anyone wants to revive this proposal in future, it is 
that counter-argument that they would need to understand and address.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 19:47, Peter Bowyer  wrote:
>
> On Tue, 20 Aug 2019 at 17:18, Peter Kokot  wrote:
>>
>> Let's simplify this a bit because I'm not sure I have seen anyone
>> mentioning something like a PHP 10 milestone in all these discussions.
>> If we want to get rid of some feature like this a very long timeline
>> needs to be done and also major versions needs to be taken into
>> consideration.
>
>
> It does indeed, and this approach was proposed by myself and another person.
>
> The approach was: add the deprecation notice in PHP 8, and remove short open 
> tags in PHP 9 or PHP 10 (purposely left vague to get more support for the 
> idea - as getting the deprecation underway is the most important move).
>
> It met with deafening silence.
>
> Peter

Then I apologize if your suggestion has been missed to do that like
this (there were too many emails stuck in loops and probably time
period of 5 to 10 years in the future is a bit problematic to
understand, and last but not least a bit of an issue when there is a
very clear feedback from people present since day 1 where they
recommend something else). I guess we should really highlight also
such option and discuss this more rationally back then. Now, we have
postponed this until who knows when and also without any clear
guideline for what will happen with short tags if they will be ever
removed or not...

--
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: PHP 7.4.0beta2 is available for testing

[Sara Golemon]

On Tue, Aug 20, 2019 at 1:58 PM Jan Ehrhardt  wrote:

> Derick Rethans in php.internals (Thu, 8 Aug 2019 09:53:28 +0100 (BST)):
> >PHP 7.4.0beta2 has just been released and can be downloaded from:
>
> Was 7.4.0beta3 skipped? 7.4.0beta4 is now tagged at Github.
> https://github.com/php/php-src/releases/tag/php-7.4.0beta4
>
> Yes. Counting is hard. Also, skipping version numbers is a proud PHP
tradition now.  RMs discussed it and we're just gonna roll with it.  There
are plenty more digits in the computer.

-Sara

Re: [PHP-DEV] RFC: var_export - short syntax for array

[Sara Golemon]

On Tue, Aug 20, 2019 at 1:05 PM Влад Макин  wrote:

> I would like to propose a little change in var_export function behavior.
> For today, this function returns string representation of array in old
> style with “array” keyword:
>
> var_export([]); // array()
>
> I think it would be better if the function returned array representation in
> modern square brackets syntax:
>
> var_export([]); // []
>
> I do like the idea of doing this, and would even be generally okay with
just making always work that way since the introduction of square bracket
syntax is really *quite* old.

The only people I could see being bothered by the change in output would be
automated code-generation suddenly seeing a (potentially quite massive)
diff as the bracket style changes.  As an example,
https://github.com/php/web-php/blob/master/include/releases.inc is a 10k
line var_export() generated list.  I'm actually /not/ bothered by the idea
of having a big point-in-time flip of that structure, though I'd want to
make sure all RMs switch versions at the same time, otherwise it could get
noisy.

Perhaps an option to quell any dissent might be to add a third param
$options to allow controlling this behavior.

function var_export(mixed $data, bool $return = false, int $options = 0):
string {}

And you could either pass EXPORT_SHORT_ARRAY or EXPORT_LONG_ARRAY or
whatever you want to call the constants depending on which behavior you'd
make default (and honestly, I think we'd make the existing format default).

-Sara

[PHP-DEV] Re: PHP 7.4.0beta2 is available for testing

[Jan Ehrhardt]

Derick Rethans in php.internals (Thu, 8 Aug 2019 09:53:28 +0100 (BST)):
>PHP 7.4.0beta2 has just been released and can be downloaded from:

Was 7.4.0beta3 skipped? 7.4.0beta4 is now tagged at Github.
https://github.com/php/php-src/releases/tag/php-7.4.0beta4
-- 
Jan

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Elevating Errors: Helpers + Formatting

[Mark Randall]

Greetings,

A week or so ago, G.P.B. submitted a pull request that contained a 
declare that would automatically elevate certain errors to Error 
exceptions (https://github.com/php/php-src/pull/4549).


As part of the discussion, Nikic stated the following:

"I believe it's okay to convert this kind of error condition to an Error 
unconditionally (I've been doing this occasionally). Basically any error 
condition that indicates a programming error and no reasonable code 
should handle locally."


Since then, G.P.B. and I have independently started looking at various 
extensions to see what the scale of the task is to convert as many 
errors as possible, and you might have noticed the PR's starting to pile up.


Before I go any further with this, and because I'm brand new to 
contributing to php-src, I think we need to discuss if we're going to 
need an API to handle these changes, particularly in respect to 
consistent formatting of error messages and error types.


As mentioned in the various PRs, there's a several situations to consider.

1) Invalid parameters where ZPP accepts mixed but internally it requires 
a specific type (example: str_replace).


2) Invalid parameters where ZPP passes but there are additional 
constraints on the value of those parameters (example: hash_xxx with 
non-cryptographic hashes).


3) Errors as the result of global state (example: session changes when a 
session is active).


For 1) and 2) there is additionally the option of where the parameter 
index is known (inside PHP_FUNCTION or passing 
INTERNAL_FUNCTION_PARAMETERS) and where it is not (where the error 
occurs within a helper function).


For my own contributions, I have added a helper function 
php_error_parameter_validation(NULL, arg_index, format, ...) that will 
format a consistent message based on its argument number and the 
formatted text.


I've got it currently throwing Error exceptions but I can forsee 
replacing certain ones with TypeError when dealing with option 1.


Before I continue, can we have a quick discussion about any helpers or 
APIs that we may want to make this more consistent, and then we can whip 
up a PR that we can then use as the basis for the rest of our changes.


Also:
As part of that PR I would also like to include a universal test script 
called trycatch_dump(...) that accepts a list of closures and runs each 
one in turn, either printing the var_dump of the result, or printing the 
error message of the exception, prefixed with the exception name.


For test cases, which are going to be the biggest part of all this, it 
reduces a 5 line try-catch per statement down to:


trycatch_dump(
  fn() => func_to_test("hello"),
  fn() => func_to_test(1234),
  fn() => func_to_test(false)
);

I am however, unsure where this script should be placed in the codebase.

Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC: var_export - short syntax for array

[Влад Макин]

Hello!

I would like to propose a little change in var_export function behavior.
For today, this function returns string representation of array in old
style with “array” keyword:

var_export([]); // array()

I think it would be better if the function returned array representation in
modern square brackets syntax:

var_export([]); // []

I think now is good time for this change because short syntax is common and
used by almost all linters as well as in examples in code standards like
PSR-2 and PSR-12.

Also this change will make it easier in the future to remove old long
syntax from PHP.

I have already implemented the concept of this feature localy (here is the
diif
).
As you can see, it does not affect a lot of the code.


This change does not break backward compability, becuse it steel returns
valid PHP array. But if it needed, this behaviour can be managed by an
additional optional function parametr.


Looking forward for your comments and suggestions

Sincerely,
Vladislav Makin

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sara Golemon]

On Tue, Aug 20, 2019 at 12:44 PM G. P. B.  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
> RFC
> > or of your arguments in favor of it that would be another story, but
> that's
> > not what happened here.
> >
>
> 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).
>
> Gotcha. So you're not actually conversing in good faith. That's helpful to
know.

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Bowyer]

On Tue, 20 Aug 2019 at 17:18, Peter Kokot  wrote:

> Let's simplify this a bit because I'm not sure I have seen anyone
> mentioning something like a PHP 10 milestone in all these discussions.
> If we want to get rid of some feature like this a very long timeline
> needs to be done and also major versions needs to be taken into
> consideration.
>

It does indeed, and this approach was proposed by myself and another
person.

The approach was: add the deprecation notice in PHP 8, and remove short
open tags in PHP 9 or PHP 10 (purposely left vague to get more support for
the idea - as getting the deprecation underway is the most important move).

It met with deafening silence.

Peter

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[G. P. B.]

2019年8月20日(火) 16:47 Rowan Tommins :

> 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é Collins)
> [IMSoP]
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php


Citation:

> Note: An RFC is effectively “owned” by the person that created 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  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 RFC
> 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  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 * only available if enabled using the 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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 17:56, Peter Kokot wrote:

Probably. But fact is that PHP opening short tags can be used. We can
enable them in controlled environments and use the short tags knowing
they will never be removed now. No deprecation warning is standing in
our way to do that now. And such code (or better put app) is honestly
now also not so bad. Because it will still work in at least let's say,
PHP 9 at least or considering the feedback and discussions for ever...
Also users who are already using short tags can now postpone the
upgrades for another ~5+ years at least :)



I don't think anything has changed in that regard. If there's text in 
the manual that short open tags are deprecated then it was wrong before 
this pair of RFCs; if there's text in the manual stating other reasons 
not to use them (portability, possibility of mixing in XML, etc) then it 
is still just as valid as it ever was.


If your impression was that the feature was already deprecated before 
the v1 RFC, and has somehow become *less* deprecated as a result of this 
vote, that may be explain some of the disconnect over the issue. As far 
as I'm aware, it had no such status, it was simply a feature that used 
to be more commonly used than it is today.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 18:39, Rowan Tommins  wrote:
>
> On 20/08/2019 17:18, Peter Kokot wrote:
> > About the docs - there are
> > very minor changes needed where "backwards compatibility" is mentioned
> > maybe. Because they are not in PHP for keeping BC anymore now. Nobody
> > proposed a better solution than this RFC, then they are a feature.
>
>
> Being "for Backwards Compatibility" and being "there forever" are not
> mutually exclusive. There are a huge number of things in this world
> which exist only to be compatible with an older technology or use case,
> but which will never be phased out, because the effort to change them
> exceeds the benefit.
>
> On the other hand, I think it might be useful to have a status of
> "officially discouraged" distinct from "deprecated". I occasionally hear
> people ask to "deprecate" something without any particular timeline or
> criteria for when it would be removed; my suspicion is that what they
> really want is a clearer message to users that they shouldn't use the
> feature.
>
> Regards,

Probably. But fact is that PHP opening short tags can be used. We can
enable them in controlled environments and use the short tags knowing
they will never be removed now. No deprecation warning is standing in
our way to do that now. And such code (or better put app) is honestly
now also not so bad. Because it will still work in at least let's say,
PHP 9 at least or considering the feedback and discussions for ever...
Also users who are already using short tags can now postpone the
upgrades for another ~5+ years at least :)

-- 
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

On 20/08/2019 17:18, Peter Kokot wrote:

About the docs - there are
very minor changes needed where "backwards compatibility" is mentioned
maybe. Because they are not in PHP for keeping BC anymore now. Nobody
proposed a better solution than this RFC, then they are a feature.



Being "for Backwards Compatibility" and being "there forever" are not 
mutually exclusive. There are a huge number of things in this world 
which exist only to be compatible with an older technology or use case, 
but which will never be phased out, because the effort to change them 
exceeds the benefit.


On the other hand, I think it might be useful to have a status of 
"officially discouraged" distinct from "deprecated". I occasionally hear 
people ask to "deprecate" something without any particular timeline or 
criteria for when it would be removed; my suspicion is that what they 
really want is a clearer message to users that they shouldn't use the 
feature.


Regards,

--
Rowan Tommins (né Collins)
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 18:02, Chase Peeler  wrote:
>
> On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot  wrote:
>
> > On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
> > >
> > > Hello internals,
> > >
> > > This RFC has been declined with 56% in favour (30/54) and 44% against
> > > (24/54).
> > >
> > > Two side notes to this:
> > >
> > >   - 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.
> > >   - As it has no clear supra majority (nor against nor in favour), this
> > > topic should probably be put to discussion again in some way or form at a
> > > later stage.
> > >
> > > Best regards
> > >
> > > George P. Banyard
> >
> > The number of things that got wrong in these two RFCs is
> > extraordinary.
>
> What was done incorrectly in regards to the second RFC?
>
>
> > If anything the community, the internals and everyone
> > involved got through a good thinking process so we have learned
> > something from this in any way. I appreciate all your time and effort
> > to move this thing forward and even for being so respectful towards
> > Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
> > PHP and to repeat the voting with a better solution in this RFC.
> >
> > You say that like being respectful to people with opinion different than
> yours is something worth commending, when it should be the default
> behavior. In other words, you are implying that anyone that opposed this
> RFC didn't deserve respect, so, congratulations to everyone for showing it
> anyway.
>
>
> > 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.
>
> If you really feel that we should start treating short tags as totally
> legitimate, then someone else with better knowledge of how to proceed with
> that will need to provide advice.
>

Let's simplify this a bit because I'm not sure I have seen anyone
mentioning something like a PHP 10 milestone in all these discussions.
If we want to get rid of some feature like this a very long timeline
needs to be done and also major versions needs to be taken into
consideration. And from all the discussions I got a feeling that not
everyone who voted "No" (who want the short tags in PHP) also want to
get rid of them. Ever. So that's why. We can live with short tags in
PHP as a feature. And so can legacy projects be upgraded to not use
them anymore so nothing to worry too much I think anymore now. We'll
discuss this maybe in 5 or 10 years then. About the docs - there are
very minor changes needed where "backwards compatibility" is mentioned
maybe. Because they are not in PHP for keeping BC anymore now. Nobody
proposed a better solution than this RFC, then they are a feature.
Cheers.

-- 
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Chase Peeler]

On Tue, Aug 20, 2019 at 11:50 AM Peter Kokot  wrote:

> On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
> >
> > Hello internals,
> >
> > This RFC has been declined with 56% in favour (30/54) and 44% against
> > (24/54).
> >
> > Two side notes to this:
> >
> >   - 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.
> >   - As it has no clear supra majority (nor against nor in favour), this
> > topic should probably be put to discussion again in some way or form at a
> > later stage.
> >
> > Best regards
> >
> > George P. Banyard
>
> The number of things that got wrong in these two RFCs is
> extraordinary.

What was done incorrectly in regards to the second RFC?


> If anything the community, the internals and everyone
> involved got through a good thinking process so we have learned
> something from this in any way. I appreciate all your time and effort
> to move this thing forward and even for being so respectful towards
> Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
> PHP and to repeat the voting with a better solution in this RFC.
>
> You say that like being respectful to people with opinion different than
yours is something worth commending, when it should be the default
behavior. In other words, you are implying that anyone that opposed this
RFC didn't deserve respect, so, congratulations to everyone for showing it
anyway.


> 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.

If you really feel that we should start treating short tags as totally
legitimate, then someone else with better knowledge of how to proceed with
that will need to provide advice.


> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Peter Kokot]

On Tue, 20 Aug 2019 at 14:51, G. P. B.  wrote:
>
> Hello internals,
>
> This RFC has been declined with 56% in favour (30/54) and 44% against
> (24/54).
>
> Two side notes to this:
>
>   - 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.
>   - As it has no clear supra majority (nor against nor in favour), this
> topic should probably be put to discussion again in some way or form at a
> later stage.
>
> Best regards
>
> George P. Banyard

The number of things that got wrong in these two RFCs is
extraordinary. If anything the community, the internals and everyone
involved got through a good thinking process so we have learned
something from this in any way. I appreciate all your time and effort
to move this thing forward and even for being so respectful towards
Zeev, Rasmus, Dmitry, and Sara who have endorsed keeping them in the
PHP and to repeat the voting with a better solution in this RFC.

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).

-- 
Peter Kokot

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Sara Golemon]

On Tue, Aug 20, 2019 at 7:51 AM 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.
>
> 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 RFC
or of your arguments in favor of it that would be another story, but that's
not what happened here.

-Sara

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[Rowan Tommins]

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é Collins)
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

[G. P. B.]

Hello internals,

This RFC has been declined with 56% in favour (30/54) and 44% against
(24/54).

Two side notes to this:

  - 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.
  - As it has no clear supra majority (nor against nor in favour), this
topic should probably be put to discussion again in some way or form at a
later stage.

Best regards

George P. Banyard

[PHP-DEV] Re: VCS Account Request: noobshow

[Olumide Samson]

Hi internals@,
I'm Olumide Samson, lead developer at Zapay Inc(a financial service
provider).

All of our backend codes are written majorly in PHP(which is a language
i've been programming in since 2007) and C(since 2006) which i write
advance sys-related programs in...

I'm hoping i could contribute to PHP Core in various ways and help grow the
Project alongside the Core Contributors we have in the Community.

I've been working on the Core code while getting familiar with the Zend
engine for over 3 weeks now, though i've commited few changes, and hoping
to do more as the Project grows...

I hope we all can make this project grow better.

Thanks,
Samson.