[PHP-DEV] Remove FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED

[Christoph M. Becker]

Hi internals!

Bug #75442[1] correctly mentions that the constants
FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED are
practically unused as of PHP 5.2.1.  (Well, they have been used in a
single test case, but I have just removed them[2]).

So I suggest to deprecate these constants as of PHP 7.3, and to remove
them as of PHP 8.0.  Would that require the RFC process?

[1] 
[2]


-- 
Christoph M. Becker

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

[PHP-DEV] Re: Consistent indentation for test files

[Christoph M. Becker]

On 28.10.2017 at 13:59, Nikita Popov wrote:

> Right now we do not have a consistent standard for the indentation of PHPT
> files. Some people create space-indented files, others create tab-indented
> files. Over time, indentation invariably starts to mix, because developers
> with different indentation settings work on one file.
> 
> Here are the current statistics for code in .phpt files:
> 
> total: 15515
> prefer tabs: 4273 (27.5%)
> prefer spaces: 6307 (40.7%)
> draw: 77 (0.5%)
> no indentation: 4858 (31.3%)
> 
> There are 1824 (11.8%) files that contain mixed tab and space indentation.
> The indentation was determined based on the first character of a line.

Thanks for bringing this up!

> I would like to propose that we establish a common standard by
> a) using space indentation for all future tests (as they currently form the
> majority), and
> b) reindenting existing test files to use space indentation.

+1

I'm rather baffled that  doesn't
address this issue at all.

-- 
Christoph M. Becker

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

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Stephen Reay]

> On 28 Oct 2017, at 18:17, Thomas Punt  wrote:
> 
> Hi Stephen,
> 
> > I disagree. To me this change would simply mean that the literal exact 
> > white-space string preceding the end marker is removed as a prefix from all 
> > lines.
> >
> > So if you have an end marker intended by two tab characters, but all the 
> > ‘content’ lines of the heredoc are indented by 8 spaces, nothing is removed.
> 
> So let's say the ending marker is indented with [space][tab][space] and the 
> body is indented with [tab][space][tab], by your logic, a [space] and a [tab] 
> should be removed from the body's indentation? Or nothing at all?
> 
> The problem with such rules is that they bring more complication to the 
> implementation when it comes down to the finer details. It is far better to 
> simply disallow such nonsense to begin with.
> 
> A nice benefit of this (choosing a stricter approach to begin with) is that, 
> should we see advantages to bringing more leniency to the current semantics 
> (such as enabling the mixture of tabs and spaces), then we can enable this 
> later without causing any new BC breaks. Whereas if we introduce a really 
> loose-style syntax to begin with, then we cannot make it stricter later on 
> without introducing new BC breaks.
> 
> -Tom

Hi Tom 

In your scenario, nothing at all would be removed. I'd imagine an exact 
substring anchored to the start-of-line is what's matched for any replacement.

Strict removal like that is the only thing I can see that makes sense - any 
conversion is likely to lead to developer surprise.

Cheers

Stephen

[PHP-DEV] Consistent indentation for test files

[Nikita Popov]

Hi internals,

Right now we do not have a consistent standard for the indentation of PHPT
files. Some people create space-indented files, others create tab-indented
files. Over time, indentation invariably starts to mix, because developers
with different indentation settings work on one file.

Here are the current statistics for code in .phpt files:

total: 15515
prefer tabs: 4273 (27.5%)
prefer spaces: 6307 (40.7%)
draw: 77 (0.5%)
no indentation: 4858 (31.3%)

There are 1824 (11.8%) files that contain mixed tab and space indentation.
The indentation was determined based on the first character of a line.

I would like to propose that we establish a common standard by
a) using space indentation for all future tests (as they currently form the
majority), and
b) reindenting existing test files to use space indentation.

Thanks,
Nikita

PS: Motivated by https://github.com/php/php-src/pull/2879. PRs regularly
have WS issues.

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Thomas Punt]

Hi Stephen,

> I disagree. To me this change would simply mean that the literal exact 
> white-space string preceding the end marker is removed as a prefix from all 
> lines.
>
> So if you have an end marker intended by two tab characters, but all the 
> ‘content’ lines of the heredoc are indented by 8 spaces, nothing is removed.

So let's say the ending marker is indented with [space][tab][space] and the 
body is indented with [tab][space][tab], by your logic, a [space] and a [tab] 
should be removed from the body's indentation? Or nothing at all?

The problem with such rules is that they bring more complication to the 
implementation when it comes down to the finer details. It is far better to 
simply disallow such nonsense to begin with.

A nice benefit of this (choosing a stricter approach to begin with) is that, 
should we see advantages to bringing more leniency to the current semantics 
(such as enabling the mixture of tabs and spaces), then we can enable this 
later without causing any new BC breaks. Whereas if we introduce a really 
loose-style syntax to begin with, then we cannot make it stricter later on 
without introducing new BC breaks.

-Tom

Re: [PHP-DEV] [RFC] Flexible Heredoc and Nowdoc Syntaxes

[Stephen Reay]

> On 24 Oct 2017, at 4:58 pm, Nikita Popov  wrote:
> 
> On Tue, Oct 24, 2017 at 11:27 AM, Thomas Punt  wrote:
> 
>> Hi Christopher,
>> 
>> 
>>> I like the added flexibility in placement of the end token, but I think
>> requiring only tabs or spaces, and stripping whitespace from all
>> {here|now}doc
>>> lines is error prone and adds unnecessary complexity.
>> 
>> I agree that the requirement for using either tabs or spaces is not
>> necessary, but
>> I included it because it does help with readability when looking at the
>> indentation
>> level of the heredoc and nowdoc (and subsequently how much whitespace will
>> be stripped from each line).
> 
> 
> It's not just a question of readability. You just can't strip a mixed
> space/tab indentation unless you specify a tab width. If one line is
> indented with two tabs and the other with 16 spaces, what do you strip? All
> 16 spaces (ts=8)? Only 8 (ts=4)? Only 4 (ts=2)? Unless we want to specify
> the One True Tab Width or introduce an ini setting for this, it's not
> really possible to handle this in a reasonable way.
> 
> With respect to the stripping of whitespace, however,
>> I feel that this is definitely necessary. If it was not stripped, then
>> indenting the
>> closing token and body will cause a lot of whitespace to prepend every
>> line in
>> the body of text. This is definitely not desirable, and may cause
>> programmers to
>> continue to not indent the body of the heredoc/nowdoc, which leads us back
>> to
>> where we currently are of having indentation of code ruined with such
>> syntaxes.
>> 
>> 
>> Other languages follow these semantics of stripping whitespace from new
>> lines
>> 
>> according to the indentation of the closing marker, such as Elixir (normal
>> """ syntax)
>> 
>> and Ruby (special <<~ syntax).
>> 
>> 
>> Thanks,
>> 
>> Tom
>> 

Hi Nikita,

I disagree. To me this change would simply mean that the literal exact 
white-space string preceding the end marker is removed as a prefix from all 
lines.

So if you have an end marker intended by two tab characters, but all the 
‘content’ lines of the heredoc are indented by 8 spaces, nothing is removed.

While I agree that features shouldn’t be surprising, I think converting tabs to 
spaces or vice-versa *would* be surprising.

Also, sidenote: ‘heredoc’ is listed as a spelling mistake with a suggestion of 
‘heretic’. Maybe the computers know more than we do.

Cheers

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

Re: [PHP-DEV] Constants and Access Modifiers

[Fleshgrinder]

On 10/27/2017 11:15 PM, Nikita Popov wrote:
> PHP does not permit self-referencing constants.
> 
> However, this is only checked when the constant is first accessed. In your
> first example the constant is never accessed, so no error is thrown. This
> has nothing to do with subclasses defining the value -- you're using late
> static binding, so you're accessing the constant of the child class
> directly.
> 
> PHP cannot detect self-referencing constants during compilation, because
> they may be formed through non-trivial cycles involving multiple constants,
> across multiple files.
> 
> Nikita
> 

My wording was maybe a bit wrong here, and I was biased by the fact that
I would like to see abstract constants. The fact that not everything can
be detected at compile time, but only later at runtime is normal in a
highly dynamic language like PHP. Self-referencing constants make no
sense, hence, it is fine. It would of course be better if the compiler
could detect that earlier, but we are not doing AOT so imho that is
fine. The behavior here is also consistent among versions as well as
HHVM, all good.

What do you think about the other ideas I raised?

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature