Re: [PHP-DEV] RFC proposal: fsync support for file resources

[David Gebler]

Thanks, my browser was automatically populating the wrong email, I've now
registered. Apparently I need to request karma now? Username dwgebler.

On Sat, Jun 6, 2020 at 12:19 AM Christoph M. Becker 
wrote:

> On 06.06.2020 at 00:00, David Gebler wrote:
>
> > As a side-note, I am unable to register a wiki.php.net account to raise
> > this RFC, I get a very unhelpful error message which just says "That
> wasn't
> > the answer we were expecting" when I submit my details. Anyone have any
> > idea what that is?
>
> I assume you're stumbling upon the CAPTCHA (fourth input field).  The
> point is, after registration you are supposed to send a mail to this
> mailing list; and that email address is asked for. :)
>
> --
> Christoph M. Becker
>

Re: [PHP-DEV] RFC proposal: fsync support for file resources

[Christoph M. Becker]

On 06.06.2020 at 00:00, David Gebler wrote:

> As a side-note, I am unable to register a wiki.php.net account to raise
> this RFC, I get a very unhelpful error message which just says "That wasn't
> the answer we were expecting" when I submit my details. Anyone have any
> idea what that is?

I assume you're stumbling upon the CAPTCHA (fourth input field).  The
point is, after registration you are supposed to send a mail to this
mailing list; and that email address is asked for. :)

--
Christoph M. Becker

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

[PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[Ilija Tovilo]

Hi internals

> I'd like to announce the match expression v2 RFC:
> https://wiki.php.net/rfc/match_expression_v2

Small reminder: Two weeks have passed since I announced the match v2
RFC with little new discussion. I'll leave it open for another two
weeks and put it to a vote then if there are no objections. I will
send another reminder one day before I do.

Ilija

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

Re: [PHP-DEV] Re: [RFC] Amendments to Attributes

[Benjamin Eberlei]

On Fri, Jun 5, 2020 at 5:58 AM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi Benjamin,
>
> Overall, all these amendments are good in my opinion, but I'd like to
> challenge a few things:
>
> 1- On item 3, the acceptable targets would be: class, function,
> method, property, class constant, parameter or all.
> If possible, I'd like to ask if it's possible to expand this list and
> also allow attribute and constructor.
>

I think this is too specific to be valuable in the language, and it could
always be validated at the attribute reading level in userland.

One thing i was thinking now, what if attributes could be "Reflection
declaration aware", example:

interface ReflectorAwareAttribute
{
 public function setReflector(Reflector $reflector);
}

class MyAttribute implements ReflectorAwareAttribute {
 public function setReflector(Reflector $reflector) {
 }
}

ReflectionAttribute::newInstance() would check for this interface and call
setReflector if present.

>
> 2- Also on item 3, the validation of PhpAttribute targets, it feels
> more natural to have this as an array instead of a bitwise or
> operator.
> Have you evaluated the performance penalty to judge your decision of
> bitwise vs array?
>

I feel this is subjective, PHP APIs generally use bitmasks for this kind of
differentiation and not an array of strings. An array of strings would have
the problem of the case with one target only: ["class"], which soon would
raise requests for a  string "class" only, where a union type is probably
more "complex" than a bitmask.

>
> 3- Repeatability should be on its own PhpAttribute. It would not block
> the expansion of the repeatability in future efforts.
> One possibility could be group repeated attributes as another
> PhpAttribute. Example: Multiple <> be folded into a
> <>.
> This code:
>
> <>
> <>
>
> Would be equivalent to (sorry if syntax is not 100% correct):
>
> < <>,
> <>
> ])>>
>
> Considering:
>
> <>
> <>
> class Schedule { public string $cron; /* ... */ }
>
> <>
> class Schedules { public array value = []; // Holds an array of Schedule  }
>

Without knowing at all how and if nested attributes get supported in the
future I feel this introduces a lot of complexity that is unnecessary.
If nested attributes are added at some point the validation could be done
in the container attributes constructor. Taking your example:

<>
class Schedules
{
public function __construct(array $schedules) {
foreach ($schedules as $schedule) {
$this->addSchedule($schedule);
}
}

private function addSchedule(Schedule $schedule) {}
}

Any kind of language support for typed arrays would obviously simplify this
even more.


> 4- Now you might have recall about my initial thoughts on this
> subject, but inheritance is something that would be very interesting
> to see as part of this amendment.
> If we introduce something like <> to the
> Attribute definition, we could then mark the Attribute to be inherited
> to subclasses of attributed class, while keeping the default to do not
> inherit anything (like we have today).
>

An equivalent of Java Annotations @Inherited is not easily possible, so we
omitted it for now.

The reason is that the compile step does not validate attributes (unless
they are internal engine attributes, that can only be provided by
extensions). So it doesn't know at that point if the declared attribute
exists and what inherit rules it might hvae defined. One solution could be
to add a new flag to ::getAttributes($name, $flags =
ReflectionAttribute::INCLUDE_INHERITED) that performs the gathering of
inherited attributes, however that will have to trigger autoloading. The
complexity and the rare use case for me speaks against adding it at the
moment.

>
> Cheers,
>
> On Thu, Jun 4, 2020 at 1:49 PM Benjamin Eberlei 
> wrote:
> >
> > On Thu, Jun 4, 2020 at 12:54 PM Benas IML 
> wrote:
> >
> > > Thank you for the update! Given that there is still an open issue, is
> the
> > > RFC proposing flags or a separate `<>` attribute?
> > >
> >
> > Good point, we came to the conclusion to simplify. Should attributes be
> in
> > the global namespace, then we shouldn't arbitrarily add more, so it will
> be
> > a flag.
> > At that point, because you rarely declare new flags we decided to merge
> > target and flags and only have one flag. You could do the following:
> >
> > <>
> >
> > >
> > > Best regards,
> > > Benas
> > >
> > > On Thu, Jun 4, 2020, 12:29 PM Benjamin Eberlei 
> > > wrote:
> > >
> > >> I have changed back the rename from namespacing to
> Attributes\Attribute to
> > >> using just Attribute after a few discussions off list. The reasoning
> is
> > >> that it becomes more clear that a majority of core contributors
> strongly
> > >> prefers using the global namespace as the PHP namespace and opening up
> > >> this
> > >> point again makes no sense. So the state of the RFC is again what it
> was
> > >> when I originally posted it with ren

Re: [PHP-DEV] RFC proposal: fsync support for file resources

[David Gebler]

As a side-note, I am unable to register a wiki.php.net account to raise
this RFC, I get a very unhelpful error message which just says "That wasn't
the answer we were expecting" when I submit my details. Anyone have any
idea what that is?

On Thu, Jun 4, 2020 at 3:19 PM David Gebler  wrote:

> It's interesting that you mention fdatasync - perhaps a better C
> programmer than I am can correct me, but I don't think it has an equivalent
> on Windows, where _commit() is a wrap on FlushFileBuffers API. So in
> respect of PHP implementation, the options would be:
>
> fdatasync() is not available on Windows, but fsync() is. fdatasync() is
> available on UNIX builds.
>
> fdatasync() on Windows is an alias of fsync(), on UNIX fdatasync() is as
> expected.
>
> Only fsync() is implemented for both Windows and Unix.
>
> -Dave
>
> On Wed, 3 Jun 2020, 11:16 Nikita Popov,  wrote:
>
>> On Mon, Jun 1, 2020 at 6:57 PM David Gebler 
>> wrote:
>>
>>> Exactly as the subject says, I would like to propose an RFC for adding an
>>> fsync() function for file resources, which would in essence be a thin
>>> wrapper around C's fsync on UNIX systems and _commit on Windows.
>>>
>>> It seems to me an odd oversight that this has never been implemented in
>>> PHP
>>> and means PHP has no way to perform durable file write operations, making
>>> it inherently unsuitable for any systems requiring more intensive I/O,
>>> mission critical logs, auditing, etc.
>>>
>>> I am not really a C programmer and I have been able to implement a simple
>>> working prototype of this as a compiled extension in merely a few hours,
>>> so
>>> I'm sure it wouldn't be difficult to bring in to the language core where
>>> the functionality really belongs.
>>>
>>> Every other major programming language otherwise comparable to PHP in
>>> features supports a way of providing durability.
>>>
>>> Thanks.
>>>
>>
>> No objections from my side. I assume you'd want to add both fsync() and
>> fdatasync()?
>>
>> I think all it takes for this one is a PR...
>>
>> Regards,
>> Nikita
>>
>

Re: [PHP-DEV] Refactoring run-tests.php

[Nikita Popov]

On Fri, Jun 5, 2020 at 5:42 PM Max Semenik  wrote:

> I was thinking about making some improvements to our venerable test runner,
> however I wasn't feeling confident about improving the present code base.
> Instead, I decided to attempt to refactor it.
>
> Here's my work in progress:  https://github.com/MaxSem/run-tests
>
> It requires Composer only for development, and has a script to make a
> single-file distribution, functionally identical to what we presently have.
>
> When it comes to integration with php-src, it could be moved to a
> subdirectory there or be kept in a separate repository and be used to
> generate a new run-tests.php whenever needed.
>
> Is there interest in this, should I continue? Any suggestions?
>

Happy to accept run-tests refactorings in general (there is a lot of global
state to eradicate!), but please keep it single-file. We definitely need it
single-file for distribution purposes, and I don't particularly want to
have a "run-tests build system" for what I perceive to be little benefit.

I'm not sure why PHP developers in particular seem to be so hung up about
this issue, but: There really is no need to split every class into a
separate file. This is how we develop in non-PHP, non-Java languages
(C/C++/Rust/...) all the time.

Regards,
Nikita

Re: [PHP-DEV] Refactoring run-tests.php

[Sara Golemon]

On Fri, Jun 5, 2020 at 10:42 AM Max Semenik  wrote:

> I was thinking about making some improvements to our venerable test runner,
> however I wasn't feeling confident about improving the present code base.
> Instead, I decided to attempt to refactor it.
>
> This is a perennial topic and I don't want to discourage you,BUT...
run-tests.php has a disturbing number of modes and edgecases, and the
preference has traditionally been for small movements which are easily
understandable individually.  That's not to say a full-refactor won't get
support, but it's a big undertaking and has defeated many brave souls.

-Sara

[PHP-DEV] Refactoring run-tests.php

[Max Semenik]

I was thinking about making some improvements to our venerable test runner,
however I wasn't feeling confident about improving the present code base.
Instead, I decided to attempt to refactor it.

Here's my work in progress:  https://github.com/MaxSem/run-tests

It requires Composer only for development, and has a script to make a
single-file distribution, functionally identical to what we presently have.

When it comes to integration with php-src, it could be moved to a
subdirectory there or be kept in a separate repository and be used to
generate a new run-tests.php whenever needed.

Is there interest in this, should I continue? Any suggestions?

-- 
Best regards,
Max Semenik

Re: [PHP-DEV] RFC karma

[Christoph M. Becker]

RFC karma granted.

Best of luck with the RFC. :)

On 05.06.2020 at 16:24, Christoph M. Becker wrote:

> On 05.06.2020 at 15:55, Gert de Pagter wrote:
>
>> Hey Internals,
>>
>> I’d like RFC karma in order to write an RFC on intersection types.
>>
>> Could someone give me the need permissions?
>>
>> Thanks in advance!
>
> Have you already registered as new Wiki user[1]?  If so, what's your
> user name?
>
> [1] 
>
> --
> Christoph M. Becker
>

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

Re: [PHP-DEV] RFC karma

[Christoph M. Becker]

On 05.06.2020 at 15:55, Gert de Pagter wrote:

> Hey Internals,
>
> I’d like RFC karma in order to write an RFC on intersection types.
>
> Could someone give me the need permissions?
>
> Thanks in advance!

Have you already registered as new Wiki user[1]?  If so, what's your
user name?

[1] 

--
Christoph M. Becker

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

[PHP-DEV] RFC karma

[Gert de Pagter]

Hey Internals,

I’d like RFC karma in order to write an RFC on intersection types.

Could someone give me the need permissions?

Thanks in advance!

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

Re: [PHP-DEV] [RFC] Named arguments

[Nikita Popov]

On Fri, Jun 5, 2020 at 12:45 PM Christian Schneider 
wrote:

> Am 05.05.2020 um 15:51 schrieb Nikita Popov :
> > \I've now updated the old proposal on this topic, and moved it back under
> > discussion: https://wiki.php.net/rfc/named_params
>
> First of all I really like this approach to Named Parameters: It seems to
> fit well with the rest of PHP.
>
> Note: I'm using the key: 'value' syntax instead of key => 'value' here but
> that's just because I prefer that syntax and think it more naturally
> extends to stuff like the shorthand syntax under "Future Scope" but that's
> not a prerequisite.
>
> I have two questions regarding to the Named Parameters which are not
> related to the LSP discussion.
> They might be restrictions of the current implementation mentioned in the
> RFC as opposed to design restrictions:
>
> 1) Could keywords be allowed as parameter names? Currently using class:
> 'foo' throws a syntax error.
> 2) Could positional parameters be allowed after named parameters for
> variadic functions?
>
> These two restrictions can be looked at separately and the only reason I'm
> bringing them up together is because the use case I'm looking at is HTML
> generation with something like a function div() being used as follows.
> Please don't discard the two questions just because you don't like this
> particular use-case, thank you ;-)
> div(class: 'error',
> div(class: 'title', "Error Title"),
> "Detailed error description...",
> )
>
> The first issue is probably mainly a parsing issue and changing T_STRING
> to identifier seems to fix it though I'm not 100% sure if there are any
> drawbacks to this.
>

Right. It should be possible to use keywords. It's a bit harder than just
replacing T_STRING with identifier, but I don't see any fundamental reason
why it shouldn't work.


> What is the main argument for not allowing positional arguments after
> named parameters for variadic functions?
> Ambiguities could still be reported if I am not mistaken.
> A work-around for the second issue would be to require an artificial
> parameter name like content taking a string or array and then do
> div(
> class: 'error',
> content: [
> div(class: 'title', content: "Error Title"),
> "Detailed error description...",
> ],
> )
> but that's somewhat more verbose without any real benefit I can see.
>

If we ignore the philosophical question of whether having positional
parameters after named is a good idea, this mostly comes down to technical
complexity. Enforcing the "named after positional" restriction is a simple
compile-time check. Without it, we would have to duplicate a large number
of argument sending instructions just for this special case. This is
basically the same reason why we don't support "foo(...$args, 1)". That's
perfectly legitimate code, but supporting it seems like more technical
complexity than it's worth.


> PS: Concerning "Future Scope: Shorthand syntax for matching parameter and
> variable name" I think allowing :$name is reasonable and thinking further
> along that line maybe variadic functions separating named from positional
> arguments could be done using func(...$positional, ...:$named) similar to
> Python's *args, **kwargs).
>

Separating positional & named variadics / unpacks in that way is certainly
a possibility, but I don't think it's the best choice for PHP. In Python
this is pretty much required, because Python has distinct list and
dictionary types. In PHP these are combined in one data structure, which
also allows us to combine them for the purpose of variadics. Combining them
makes sure that existing code using variadic forwarding will "just work"
with named parameters -- but of course, it also means that some code will
accept named parameters even though it was not explicitly designed with
that in mind. There's a trade-off there.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Named arguments

[Christian Schneider]

Am 05.05.2020 um 15:51 schrieb Nikita Popov :
> \I've now updated the old proposal on this topic, and moved it back under
> discussion: https://wiki.php.net/rfc/named_params

First of all I really like this approach to Named Parameters: It seems to fit 
well with the rest of PHP.

Note: I'm using the key: 'value' syntax instead of key => 'value' here but 
that's just because I prefer that syntax and think it more naturally extends to 
stuff like the shorthand syntax under "Future Scope" but that's not a 
prerequisite.

I have two questions regarding to the Named Parameters which are not related to 
the LSP discussion.
They might be restrictions of the current implementation mentioned in the RFC 
as opposed to design restrictions:

1) Could keywords be allowed as parameter names? Currently using class: 'foo' 
throws a syntax error.
2) Could positional parameters be allowed after named parameters for variadic 
functions?

These two restrictions can be looked at separately and the only reason I'm 
bringing them up together is because the use case I'm looking at is HTML 
generation with something like a function div() being used as follows.
Please don't discard the two questions just because you don't like this 
particular use-case, thank you ;-)
div(class: 'error',
div(class: 'title', "Error Title"),
"Detailed error description...",
)

The first issue is probably mainly a parsing issue and changing T_STRING to 
identifier seems to fix it though I'm not 100% sure if there are any drawbacks 
to this.

What is the main argument for not allowing positional arguments after named 
parameters for variadic functions?
Ambiguities could still be reported if I am not mistaken.
A work-around for the second issue would be to require an artificial parameter 
name like content taking a string or array and then do
div(
class: 'error',
content: [
div(class: 'title', content: "Error Title"),
"Detailed error description...",
],
)
but that's somewhat more verbose without any real benefit I can see.

PS: Concerning "Future Scope: Shorthand syntax for matching parameter and 
variable name" I think allowing :$name is reasonable and thinking further along 
that line maybe variadic functions separating named from positional arguments 
could be done using func(...$positional, ...:$named) similar to Python's *args, 
**kwargs).

- Chris

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

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0

[Nikita Popov]

On Fri, Jun 5, 2020 at 11:14 AM Nicolas Grekas 
wrote:

>
> It's that time of year again. Feature freeze is looming, so it's time to
>> talk about deprecations!
>>
>> https://wiki.php.net/rfc/deprecations_php_8_0
>>
>
> Thanks for the RFC.
> Would it make sense for you to postpone this for 8.1?
> I'm talking with my experience on Symfony here: we decided to give ppl
> some rest when they upgrade and always have our *.0 versions
> deprecations-free.
> Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the
> additional step of solving deprecations is extra work that is not needed
> yet. I know solving deprecations is optional, but many teams have CI that
> fail on deprecations.
>
> I think it could be nicer to the userland community to have a smother path
> here, IMHO.
>
> Nicolas
>

Hey Nicolas,

I'm certainly open to that! I don't think there's any strong reason to
deprecate any of these in PHP 8.0 in particular, as we'll only be able to
drop them in PHP 9.0 anyway. Anyone else have thoughts on that?

We do already have a couple of deprecation in PHP 8.0, but those are
generally directly related to some change that happened in PHP 8.0 in
particular.

Regards,
Nikita

Re: [PHP-DEV] [RFC] Deprecations for PHP 8.0

[Nicolas Grekas]

> It's that time of year again. Feature freeze is looming, so it's time to
> talk about deprecations!
>
> https://wiki.php.net/rfc/deprecations_php_8_0
>

Thanks for the RFC.
Would it make sense for you to postpone this for 8.1?
I'm talking with my experience on Symfony here: we decided to give ppl some
rest when they upgrade and always have our *.0 versions deprecations-free.
Chasing BC breaks is a hard enough task for ppl to upgrade. Adding the
additional step of solving deprecations is extra work that is not needed
yet. I know solving deprecations is optional, but many teams have CI that
fail on deprecations.

I think it could be nicer to the userland community to have a smother path
here, IMHO.

Nicolas

[PHP-DEV] [RFC] Deprecations for PHP 8.0

[Nikita Popov]

Hi internals,

It's that time of year again. Feature freeze is looming, so it's time to
talk about deprecations!

https://wiki.php.net/rfc/deprecations_php_8_0

The procedure is as usual. There are multiple deprecations part of the RFC,
but they will be voted separately.

If you would like to add something to the list, please try to provide an
extended rationale (but I reserve the right to not include it, if I
consider it too controversial.) I'm also happy to remove deprecations or
adjust their scope, if there are good arguments for doing that. Consider
this more as a point to start discussion than a finalized proposal.

Regards,
Nikita