Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums

[Benjamin Eberlei]

On Wed, Jun 22, 2022 at 6:01 PM Nicolas Grekas 
wrote:

> Hi Benjamin and Derick,
>
> I'm replying to both of you because I see some things in common in your
> comments.
>
> >
>> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
>
> I would prefer if this was an explicit opt-in to have a __toString on a
>> backed enum. Maybe a special trait for enums that has the implementation,
>> so that a custom __toString cannot be implemented or a new syntax "enum Foo
>> : Stringable".
>>
>
> We can make this opt-in by simply allowing user-land to implement
> Stringable.
> This is a different solution to the problem the RFC tries to solve and I
> would also personally be fine with.
> I would then *not* try to limit which implementation of it is allowed by
> the engine. Instead, I would give all powers to user-land to decide on
> their own what makes sense for their use case. As a general principle, I
> believe that empowering user-land is always a win vs trying to "save them
> from themselves", as if we knew better than them what they want to achieve,
> and especially how.
>
>
>> My concern is that auto implementing __toString, will lead to decreasing
>> type safety of enums in weak typing mode, since they get auto-casted to
>> string when passed to a function accepting strings. This effectively adds
>> more type juggling cases.
>>
>
> I don't share this concern: if an API accepts a string and the engine can
> provide a string, let it do so. There is nothing inherently dangerous in
> doing so. But we don't need to agree on that if the proposal above makes
> sense to everybody :)
>
>
>> The example in the RFC about attributes accepting strings or Enums can be
>> solved by union types on the side of the library developers, it doesn't
>> need to be magically implemented by the engine.
>>
>
> I extensively explain in the RFC why this should not be on the side of lib
> authors, but on the side of end-users. Please double check and let me know
> your thoughts.
>

I don't fully agree with your argument in the RFC.

You mention as an exmaple that users want to pass PossibleRoles enum values
into the IsGranted attribute. But the way Symfony works as you know, you
can pass arbitrary role names here from the library POV, and applications
can add their own. So naturally the API is to pass a string. So
"PossibleRoles" can only be a user provided enum, it can never be a Symfony
type.

I don't see how PHP should provide a workaround for Symfony and its users
wanting to allow users to use an arbitrary enum as input to a function.

In this example, in Symfony code you only expect "any" BackedEnum and
cannot validate that it is a value of PossibleRoles enum. As such Rowan
suggestion to use constants is the way Symfony should recommend their users.


>
>> I don't consider "use strict mode" a good argument to avoid this problem,
>> because that has other downsides such as overcasting.
>>
>
> I'm 100% aligned with that.
>
> 2. It is not implemented for all enum types, only for string backed ones.
>> This change would now make different classes of enums, without them being
>> differently inherited classes.
>>
>
> This would also be solved by allowing user-land to implement Stringable on
> *all* kind of enums. Would that make sense to you?
>
>
>> 3. The main use case seems to be to prevent having to type ->value, which
>> would otherwise indicate reliably whether an enum is used as string
>> argument.
>>
>
> Yep, that's a "strict mode" approach and this RFC mostly applies to
> non-strict mode.
> There are also cases where using "->value" is just not possible. I mention
> attributes in the RFC, but we also have a case in Symfony where defining
> service definitions in yaml doesn't work with enums because there is no way
> to express the "->value" part.
>
> If that's the consensus, I'm fine updating the RFC to turn the vote into
> whether "allowing user-land to implement Stringable on any kind of enums"
> is desired or not.
>
> Nicolas
>

Re: [PHP-DEV] [RFC] [Under Discussion] Auto-implement Stringable for string backed enums

[Benjamin Eberlei]

On Wed, Jun 22, 2022 at 12:47 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:

> Hi everyone!
>
> I'd like to open a discussion on this RFC, to auto-implement Stringable for
> string-backed enums:
> https://wiki.php.net/rfc/auto-implement_stringable_for_string_backed_enums
>
> I'm looking forward to your feedback,


Hi Nicolas, Hi Ilija,

I would prefer if this was an explicit opt-in to have a __toString on a
backed enum. Maybe a special trait for enums that has the implementation,
so that a custom __toString cannot be implemented or a new syntax "enum Foo
: Stringable".

My concern is that auto implementing __toString, will lead to decreasing
type safety of enums in weak typing mode, since they get auto-casted to
string when passed to a function accepting strings. This effectively adds
more type juggling cases.

The example in the RFC about attributes accepting strings or Enums can be
solved by union types on the side of the library developers, it doesn't
need to be magically implemented by the engine.

I don't consider "use strict mode" a good argument to avoid this problem,
because that has other downsides such as overcasting.

>
> Cheers,
> Nicolas
>

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Benjamin Eberlei]

Hi Tim,

On Mon, Jan 10, 2022 at 3:06 PM Tim Düsterhus, WoltLab GmbH <
duester...@woltlab.com> wrote:

> Hi Internals!
>
> this is a follow-up for my "Pre-RFC" email from last Friday, January, 7th.
>
> Christoph Becker granted me RFC editing permissions and I've now written
> up our proposal as a proper RFC:
>
> https://wiki.php.net/rfc/redact_parameters_in_back_traces


This is a very good addition in my opinion. And as one of the attributes
RFC authors I am thrilled about their use here ;-)

I believe it wouldn't hurt the RFC to add more words around the fact that
stacktraces are often sent to third party services (Exception Tracking
software) and as such a redaction of the parameters would be powerful for
additional redaction of credit cards, email addresses and other personal
data. The example with PDO::__construct is an obvious choice to redact
passwords, but application level data is a second source of input that is
critical to redact.

>
>
> I recommend also taking a look at my previous email:
>
> https://externals.io/message/116847
>
> It contains some additional context that did not really fit within the
> language of a "neutral" RFC that will remain as the permanent record.
>
> - As indicated within the RFC and my previous email we still need a more
> experienced developer for the final implementation, as I have next to no
> experience with PHP's implementation.
>
> Specifically adding this attribute to existing functions is not clear to
> me. It is probably required to update the stub parser/generator to add
> support for attributes? If someone creates an example implementation for
> one function, I'll likely be able to apply this to other functions myself.
> - The RFC Impact to Opcache is not clear to me. I don't believe there is
> any, but I am not sure. So if someone knows, I'm happy to update that
> section.
>
> Best regards
> Tim Düsterhus
> Developer WoltLab GmbH
>
> --
>
> WoltLab GmbH
> Nedlitzer Str. 27B
> 14469 Potsdam
>
> Tel.: +49 331 96784338
>
> duester...@woltlab.com
> www.woltlab.com
>
> Managing director:
> Marcel Werk
>
> AG Potsdam HRB 26795 P
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties

[Benjamin Eberlei]

On Mon, Nov 15, 2021 at 1:52 PM Andreas Heigl  wrote:

> Hea all.
>
> On 15.11.21 10:52, Derick Rethans wrote:
> > Dear Internals,
> >
> > On Wed, 10 Nov 2021, Nikita Popov wrote:
> >
> >> On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov 
> wrote:
> >>
> >>> This RFC takes the more direct route of deprecating this
> >>> functionality entirely. I expect that this will have relatively
> >>> little impact on modern code (e.g. in Symfony I could fix the vast
> >>> majority of deprecation warnings with a three-line diff), but may
> >>> have a big impact on legacy code that doesn't declare properties at
> >>> all.
> >>>
> >>
> >> I plan to open voting on this RFC soon. Most of the feedback was
> >> positive, apart from the initial choice of opt-int mechanism, and that
> >> part should be addressed by the switch to the
> >> #[AllowDynamicProperties] attribute.
> >
> > The voting is now open, but I think one thing was not taken into account
> > here, the many small changes that push work to maintainers of Open
> > Source library and CI related tools.
> >
> > In the last few years, the release cadence of PHP has increased, which
> > is great for new features. It however has not been helpful to introduce
> > many small deprecations and BC breaks in every single release.
> >
> > This invariably is making maintainers of Open Source anxious, and
> > frustrated as so much work is need to keep things up to date. I know
> > they are *deprecations*, and applications can turn these off, but that's
> > not the case for maintainers of libraries.
> >
> > Before we introduce many more of this into PHP 8.2, I think it would be
> > wise to figure out a way how to:
> >
> > - improve the langauge with new features
> > - keep maintenance cost for open source library and CI tools much lower
> > - come up with a set of guidelines for when it is necessary to introduce
> >BC breaks and deprecations.
> >
> > I am all for improving the language and making it more feature rich, but
> > we have not spend enough time considering the impacts to the full
> > ecosystem.
> >
> > I have therefore voted "no" on this RFC, and I hope you will too.
> >
> > cheers,
> > Derick
>
> After some thoughs on this RFC I have reverted my original vote and
> voted "No" due to several reasons.
>
> For one thing it is not clear to me what the benefits are. Yes: The
> language evolution RFC talks about "Forbidding dynamic object
> properties" but it also specifies that "there is also a lot of old code
> that does not declare properties, so this needs to be opt-in"[1].
>
> And as far as I can see from the PR associated with this RFC it will not
> make life easier for the internals team. It is not like there will be
> hundreds of lines code less to maintain. On the contrary. There is more
> code and more logic to maintain [2].
>

This RFCs goal is not to have less code to maintain, but to fix a nasty
class of errors in user errors where they accidently write/read to a
dynamic property due to a typo, instead of accessing the declared one.

True this is a mistake of the RFC not to highlight more.


> So when the only reason for the change is that one line in the RFC ("In
> modern code, this is rarely done intentionally"[3]) then that is not
> enough of a reasoning for me for such a code change that requires a lot
> of existing code to change.
>
> Those that want a cleaner code can already use static code analysis to
> find such issues (if not, I'm sure that there will be some analyzers
> around before PHP8.2 will be around) or write appropriate tests to make
> sure that they do not use undeclared properties.
>

Code that intentionally or unintentionally uses dynamic properties often
does not write each propery explicitly:

$object->$columnName = $value;

This cannot be detected by static analysers.

For the case where you explitly write a property name, While static
analysis and IDEs do help detecing these as problems, this class of bugs
happens because you are *not* using an IDE but a text editor like
Vim/Notepad++ where you maybe add a typo to a property name while writing
code.


> While I personally would really like to deprecate dynamic properties I
> believe that it is the wrong thing to do for the language. At least
> given the presented arguments why we should do it.
>
> Cheers
>
> Andreas
>
> PS: Am I the only one missing whether this is a 2/3 or a 50%+1 vote in
> the RFC?
>
>
>
> [1]
>
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md#forbidding-dynamic-object-properties
> [2] https://github.com/php/php-src/pull/7571/files
> [3] https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> --
>,,,
>   (o o)
> +-ooO-(_)-Ooo-+
> | Andreas Heigl   |
> | mailto:andr...@heigl.org  

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Benjamin Eberlei]

On Mon, Nov 15, 2021 at 11:26 AM Nicolas Grekas <
nicolas.grekas+...@gmail.com> wrote:

> Hi Nikita, hi everybody,
>
> Le mer. 25 août 2021 à 12:03, Nikita Popov  a écrit
> :
>
> > Hi internals,
> >
> > I'd like to propose the deprecation of "dynamic properties", that is
> > properties that have not been declared in the class (stdClass and
> > __get/__set excluded, of course):
> >
> > https://wiki.php.net/rfc/deprecate_dynamic_properties
> >
> > This has been discussed in various forms in the past, e.g. in
> > https://wiki.php.net/rfc/locked-classes as a class modifier and
> > https://wiki.php.net/rfc/namespace_scoped_declares /
> >
> >
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
> > as a declare directive.
> >
> > This RFC takes the more direct route of deprecating this functionality
> > entirely. I expect that this will have relatively little impact on modern
> > code (e.g. in Symfony I could fix the vast majority of deprecation
> warnings
> > with a three-line diff), but may have a big impact on legacy code that
> > doesn't declare properties at all.
> >
>
> Thanks for the RFC, it makes sense to me and I support the move.
>
> Since Symfony is mentioned in the RFC, I thought you might want to know
> about this PR, that removes dynamic properties from the Symfony codebase:
> https://github.com/symfony/symfony/pull/44037/files
>
> What Nikita describes in the RFC is correct: declaring+unsetting the
> "groups" property works.
> There's just one more thing I had to do; I also had to replace two calls to
> property_exists:
>
> -if (!property_exists($this, 'groups')) {
> +if (!isset(((array) $this)['groups'])) {
>
> The rest are test cases where we've been lazily accepting fixtures with
> undeclared properties. No big deal, and I'm happy the engine might soon
> help us get a bit stricter in this regard.
>
> I read that some think that this PR is not required because static
> analysers (SA) can report when a dynamic property is used. Although that's
> correct, I think it would be detrimental to PHP as a language if SA tools
> (or any tools actually) were a requirement to code in the safe-n-modern
> way. You should not have to install any complex safeguarding tooling
> infrastructure to start coding; both for newcomers, but also for
> no-so-new-comers.
>

Its not so true from my POV that static analysis can avoid having this
deprecation:

1. static analysis does not work for dynamic assignments,

$object = new SomeDataObject();
$row = $pdo->fetch();
foreach ($row as $column => $value) {
$object->$column = $value;
}

arguably this is one of the important use cases this deprecation fixes.

A second example of this is when doing deserialization into an object from
JSON or XML:

$object = new SomeDataObject();
$objectPayload = json_decode($input, true);
foreach ($objectPayload as $prop => $value) {
$object->$prop = $value;
}

This doesn't apply sole to user input where maybe more validation of input
is necessary, but also for mapping config files to an object.

All this kind of generic code cannot be statically analysed, but this
deprecation and removal has the most value in exactly that use-case.


>
> About the discussion related to deprecations. I've yet to see a better
> reporting system than the current one.
> It's true that too many userland error handlers are throwing instead of
> collecting/logging/skipping deprecations.
> But these can be fixed (and many are being fixed these days, which is
> nice!)
>
> Cheers,
> Nicolas
>

Re: [PHP-DEV] Adding a way to disable the stat cache

[Benjamin Eberlei]

On Fri, Sep 3, 2021 at 11:51 PM Hans Henrik Bergan 
wrote:

> PS i've seen *HORRIBLE* fs performance for php-running-on-windows,
> where the same filesystem operations on the same files took like 5 seconds
> on linux-running-on-vmware-on-laptop-running-windows-10, versus several
> minutes for the same operation on the same laptop on windows 10 directly..
> for people looking for best-case-scenario for the stat cache, try looking
> at windows fs performance.. (if anyone even cares about that? i personally
> don't, i never run anything performance-sensitive-php code on Windows, just
> noticed horrible fs performance in the past)
>

The stat cache does not necessarily solve this issues though, only in very
limited cases where you work with the *same* file over and over again. The
stat cache only ever has exactly one entry, the *last* file that was
accessed. So if you work with many diferent files the stat cache does not
do what you would expect, to store the information of all these files. It
overwrites the cache with a new file entry when its not the same file as
currently stored.

>
> On Fri, 3 Sept 2021 at 22:22, Kevin Lyda  wrote:
>
> > On Fri, Sep 3, 2021 at 9:12 PM Christian Schneider
> >  wrote:
> > > I'm interested in the load put on a system with a high request count
> and
> > a typical application.
> > > Reducing system calls used to matter there as the kernel does not
> > multi-process the same way user land does.
> > >
> > > But then again, maybe I'm overly cautious :-)
> >
> > This PR allows people to do just that experiment.
> >
> > Kevin
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>

Re: [PHP-DEV] [RFC] Nullable intersection types

[Benjamin Eberlei]

On Fri, Jul 23, 2021 at 4:31 PM Deleu  wrote:

> On Fri, Jul 23, 2021 at 2:36 PM Derick Rethans  wrote:
>
> > From the RFC: «Taking all these elements into account, the preference
> > of... and thus to use the "?X&Y" syntax».
> >
> > I think this would be a mistake. You touch upon operator precedence, and
> > needing to know whether | or & is higher, and inventing a new precedence
> > for ?.
> >
> > I would strongly advocate for not getting into the realm with any
> > operator precendence, but instead *require* parenthesis for any
> > combination. This gives the code reader and writer an immediate clue
> > about what the code does. Most coding standards also recommend this for
> > expressions in "if" statements and the like.
> >
> > I do however agree with Sara's «over-delivering syntax that hasn't been
> > entirely thought through» point. It will take a lot longer to come up
> > with a proposal to combine intersection and union types.
> >
> > That in combination that you're proposing this RFC after feature freeze,
> > while you've had four months to make this arguments as part of the "Pure
> > Intersection Types" RFC, I am currently not going to support this RFC
> > for inclusion into PHP 8.1.
> >
> > cheers,
> > Derick
> >
> > --
> > PHP 7.4 Release Manager
> > Host of PHP Internals News: https://phpinternals.news
> > Like Xdebug? Consider supporting me: https://xdebug.org/support
> > https://derickrethans.nl | https://xdebug.org | https://dram.io
> > twitter: @derickr and @xdebug
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
>
>
> These are precisely everything I think about this RFC. The only thing the
> RFC made clear is why it is easy to make an exception for null while still
> not providing a full mix of union and intersection.
>
> Maybe my memory is also really bad, but the RFC makes it seem like version
> 7.0 was a mistake to be learned from which isn't clear for me. I understand
> that introducing nullable intersection later will warrant a major version
> and I don't see a problem with that. Pure Intersection RFC was such a
> breeze vote precisely because it didn't involve the complexity of mixing
> with union. Part of that complexity is now being rushed after feature
> freeze.
>

As a maintainer of a large open source library, yes 7.0 was a problem due
to the nullability missing for return types and was the reason why a lot of
open source libraries jumped from minimum 5.4/5.5/5.6 directly to 7.1 to
avoid breaking BC twice for classes/interfaces when a signature of the
following kind was present:

/**
* @param string $foo
 * @return ?string
 */
function foo () { }

php 7.0: foo(string $foo) {}
php 7.1: foo(string $foo) : ?string {}


> --
> Marco Aurélio Deleu
>

Re: [PHP-DEV] Re: [RFC] Nullable intersection types

[Benjamin Eberlei]

On Fri, Jul 23, 2021 at 12:55 PM Mark Randall  wrote:

> On 23/07/2021 10:58, Nicolas Grekas wrote:
> > Hi everyone,
> > I wrote everything down about the reasons why here:
> > https://wiki.php.net/rfc/nullable_intersection_types
>
>
> IMO we should require brackets and forbid not using them when combining
> unions and intersections.
>
> These types are already going to be confusing enough and we can likely
> save a fair amount of confusion and pain down the line by requiring the
> explicit brackets.
>
> Without wanting to bikeshed, let's just make sure we're set on ()
> because whatever we choose here will be the defacto mechanism for
> declaring sub-types in PHP for the rest of eternity so it would need to
> be maximally compatible with everything we might want to do with them.
>

This is also my preference to have it (A&B)|null - It is the least
"disruptive" change for this late stage of the release cycle and leaves the
most potential for future improvements.

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

Re: [PHP-DEV] [Vote] New in initializers

[Benjamin Eberlei]

On Tue, Jul 6, 2021 at 12:58 PM Rowan Tommins 
wrote:

> On 06/07/2021 11:31, Benjamin Eberlei wrote:
> > This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
> > then calling ReflectionAttribute::getArguments would also require to
> > resolve the type Foo. So this is not different than what could happen
> right
> > now already.
>
>
> Despite its name, "::class" doesn't care about class definitions, it
> just performs a string substitution based on the "namespace" and "use"
> statements in the current file.
>
> In most cases, that happens entirely at compile time, so the following
> two source files compile identically:
>

Hah, I realized after sending the example was bad :) I should have used an
example using actual constants (vs magic ones):

#[Foo(Foo::BAR)]

This would trigger autoloading and resolving during getArguments()

>
> Short form:
>
> namespace Somebody\Something;
> #[ Foo( Foo::class ) ]
> class Whatever {}
>
> Expanded form:
>
> namespace Somebody\Something;
> #[ \Somebody\Something\Foo( '\Somebody\Something\Foo' ) ]
> class Whatever {}
>
>
> There is no need for the class \Somebody\Something\Foo to actually exist
> in either case, the argument is just a string:
> https://3v4l.org/bgNa2#v8.0.8
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [Vote] New in initializers

[Benjamin Eberlei]

On Tue, Jul 6, 2021 at 9:31 AM Nicolas Grekas 
wrote:

> Hi NIkita,
>
> I've opened voting on https://wiki.php.net/rfc/new_in_initializers. Voting
> > will close on 2021-07-14.
> >
> > Note that relative to the original RFC, new support is limited to
> parameter
> > default values, attribute arguments, static variable initializers and
> > global constant initializers, and not supported in property initializers
> > and class constant initializers. The discussion thread
> > https://externals.io/message/113347 has some extensive information on
> how
> > we got here.
> >
>
> I voted yes and I'm happy this will come to PHP.
>
> I realized I still have one concern that I want to share here, related to
> attributes:
> The RFC breaks the possibility to parse the arguments of an attribute in a
> generic and safe way.
> What I mean is that right now, attributes can be inspected while the
> corresponding classes are not installed, due eg to a missing optional
> dependency.
>

This is not 100% correct, you can have an attribte #[Foo(Foo::class)] and
then calling ReflectionAttribute::getArguments would also require to
resolve the type Foo. So this is not different than what could happen right
now already.

What you can do is use `ReflectionAttribute::getName()` to filter the
attributes you want to work on and only then call getArguments().


> This behavior is what makes attributes truly declarative: one can ignore
> what they don't care about. Extra semantics can be carried out by classes
> without making the related attributes a mandatory dependency.
>
> I think there is a way to preserve this behavior and that we should look
> for it.
>
> If I may propose one: we might add a new
> ReflectionAttribute::getUninitializedArguments() method, that would return
> the same as ReflectionAttribute::getArguments(), except that it would put a
> ReflectionAttribute (or similar) instance in place of objects in the data
> structure. As a corollary, we might also want to enforce that only child
> classes of the Attribute class can be nested inside another Attribute (at
> least if we want to reuse ReflectionAttribute as a placeholder.)
>

A function like this could return all arguments that are not AST Nodes but
"literals" (instances of scalar / array types).
Foo::class or new Foo() are both AST Node types that are resolved the same
way in `getArguments`.


>
> WDYT?
>
> Nicolas
>

Re: [PHP-DEV] [Vote] Partial Function Application

[Benjamin Eberlei]

On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield 
wrote:

> Hi folks.  The vote for the Partial Function Application RFC is now open,
> and will run until 30 June.
>
> https://wiki.php.net/rfc/partial_function_application
>
> Of particular note, a few people had asked about using ...? instead of ...
> for the variadic placeholder.  In the end we decided not to explore that,
> as Nikita explained off-list it was actually more confusing, not less, as
> it would suggest "placeholder for a variadic" rather than "a placeholder
> that is variadic."  Otherwise, it's just more typing.  The syntax choices
> section of the RFC has been updated accordingly.
>

I wanted to explain my no vote on this one.

The examples section shows how every use-case of partials can be done using
short functions and while this is often a lot more to type (especially if
you mirror the typehints), these extra symbols feel necessary from my POV
to make the code clear that creates a partial.

Especially the ... as "additional" arguments and its various interactions
with ? produce so many different ways of calling something, it feels
unnecessary to me to introduce this complexity to newbies that might come
across use of this functionality. Plus the additional edge cases of delayed
execution, non-support for named parameters. Its a lot to know to fully
understand this feature.

Given that the functional paradigm isn't widely spread in use across PHP
developers, i am not convinced that we should add more features in this
direction that increase the complexity of understanding the language by
that much. While one could argue that functional paradigm isn't
wide-spread, because these features are missing, it is my believe that the
majority of PHP developers would still rather prefer imperative coding.

As a thought experiment I tried to think of code in our codebase that we
could convert to PFA once we migrated to 8.1 and there just isn't that
much. This is very different to short functions, nullabilty operator and
other "glue" / sugar proposals that were added to the language lately,
which a lot of existing code benefits from and existing code could be
converted automatically to them using phpcs/phpcbf rules.

I also am wary of the future after this RFC, as it states it is the
launching pad to another attempt at the Pipe Operator, which also proposes
to do a thing (calling functions) in a completly new way that will be hard
for beginners. I hope we don't add both these features to keep the language
smaller in this aspect of how functions are called.


> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Readonly properties

[Benjamin Eberlei]

On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>

I have a question about Reflection support, the RFC states:

> ReflectionProperty::setValue() can bypass the requirement that
initialization occurs from the scope where the property has been declared.
However, reflection cannot modify a readonly property that has already been
initialized.

Is there a reason why this is not possible? I am thinking about ORMs or
Deserializers here where a pattern would be:

class MyDataObject
{
public function __construct(
public readonly $foo
) {}
}

$dataObject = $reflectionClass->newInstanceWithoutConstructor();
$dataObject->getProperty('foo')->setValue($row['value']);


>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC] Readonly properties

[Benjamin Eberlei]

On Fri, Jun 4, 2021 at 5:20 PM Nikita Popov  wrote:

> Hi internals,
>
> I'd like to open the discussion on readonly properties:
> https://wiki.php.net/rfc/readonly_properties_v2
>
> This proposal is similar to the
> https://wiki.php.net/rfc/write_once_properties RFC that has been declined
> previously. One significant difference is that the new RFC limits the scope
> of initializing assignments. I think a key mistake of the previous RFC was
> the confusing "write-once" framing, which is both technically correct and
> quite irrelevant.
>
> Please see the rationale section (
> https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> proposal relates to other RFCs and alternatives.
>

I have a question about Reflection support, the RFC states:

> ReflectionProperty::setValue() can bypass the requirement that
initialization occurs from the scope where the property has been declared.
However, reflection cannot modify a readonly property that has already been
initialized.

Is there a reason why this is not possible? I am thinking about ORMs or
Deserializers here where a pattern would be:

class MyDataObject
{
public function __construct(
public readonly $foo
) {}
}

$dataObject = $reflectionClass->newInstanceWithoutConstructor();
$dataObject->getProperty('foo')->setValue($row['value']);

>
> Regards,
> Nikita
>

Re: [PHP-DEV] Bugsnet

[Benjamin Eberlei]

On Sun, May 9, 2021 at 8:49 AM Joe Watkins  wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>

One downside of this "easy access" is that Github Issues tend to get used
as support question forum, at least from my experience on Doctrine it can
easily be 50% of the issues that are support questions. This is much more
work to process than simple spam issues, because there is a human on the
other side who need to be directed towards the proper support channel.

In addition I agree with Rowans assessment that large projects usually have
lots of automation in place on top of Github issues that we would again
need to configure, write or maintain in one way or another.

bugsweb on the other hand is a "classic LAMP" stack application, so maybe
we could look into removing the infrastructure variable from the hosting
equation and look for a PaaS provider? Spam protection third party services
are also available and might potentially be integrated with in a reasonable
amount of time.


> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the r

Re: [PHP-DEV] [RFC][Draft] Sealed Classes

[Benjamin Eberlei]

On Sat, Apr 24, 2021 at 2:56 PM Pierre  wrote:

> Le 24/04/2021 à 12:55, Saif Eddin Gmati a écrit :
> > Hello Internals,
> >
> > I'm sending this email to open discussion about sealed classes,
> > interfaces, and traits feature for PHP 8.1.
> >
> > I have create a Draft RFC here:
> > https://wiki.php.net/rfc/sealed_classes
> > 
> >
> > A major concern for few people have been the syntax, in which it
> > introduces 2 new keywords into the languages, therefor, i have added a
> > section about alternative syntax which could be used to avoid this
> > problem.
> >
> > Regards,
> >
> > Saif.
>
> Hello,
>
> And why not using an attribute, such as in HackLang ?
>

+1 on this, I said the same on the "never/noreturn" RFC. There is a much
less invasive way to add new keywords/flags to functions by using
attributes.

Imho this decouples new features from the language and reduces the "risk"
of adding them to the language. That should increase the likeliness of it
getting accepted in my opinion.

>
> Regards,
>
> --
>
> Pierre
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] noreturn type

[Benjamin Eberlei]

On Sat, Apr 3, 2021 at 5:30 PM Benjamin Eberlei  wrote:

>
>
> On Fri, Apr 2, 2021 at 3:14 AM Aaron Piotrowski  wrote:
>
>>
>> > On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals <
>> internals@lists.php.net> wrote:
>> >
>> > I do not care which name is chosen, but if we are going to have this
>> > sort of thing in the language, it ought to be a bottom type, not an
>> > attribute.
>> >
>>
>> You make an excellent point Levi. I initially chose `noreturn` simply
>> because I was familiar with the name from C and didn't have a strong
>> opinion. However, I agree that `noreturn` is a poor choice for reuse as a
>> bottom type, so I changed my vote to `never`.
>>
>
> i voted against this proposal, but changed my choice of "noreturn" to
> "never", because it would ultimately be slightly less bad to have this name
> for use as a bottom type. The name "never" is still unfortunate, because it
> transmits "behavior" of being used in the context of a function, a better
> name might have been "nothing" as Levi suggests.
>
> But I again get to the point of the problem with this RFC due to naming.
> "never" is actually combining "nothing" type with "noreturn" flag, so for
> me the most consistent way would have been "public noreturn function foo():
> nothing"
>

Sorry, i should have been more detailed/precise before:

Why i think "never" is not a great solution, if you have the same example
that TypeScript uses to explain their "never":

if (is_string($value) && is_int($value)) {
   // inside here $value is_type == "never"
}

The naming "never" here makes no sense, because from a theoretical
perspective reasoning about the type of $value it is nothing and only the
block of code is "never reached".

I suppose PHPStan and Psalm are eager to reuse the new type name for this
kind of type interference, same as TypeScript does. The name is sub
optiomal outside the context of a return type.

So lets say we seperate the two behaviors of "never" into "nothing +
noreturn".

public noreturn function foo(): nothing {
exit();
}

But adding a new keyword "noreturn" would not be necessary, it could just
be an Attribute as i said in my first e-mail explaining my no-vote:

#[NoReturn] // sets a function flag modifying the void behavior
public function foo(): nothing {
return; // throws if it reaches this point
}

This would be closer to what Psalm and PHP-Stan use at the moment if we
replace nothing with void.

The problem is that "void" is already not perfect, since the callside
doesn't care about "return null" with no return type vs "return" + void
return type.

If we had "nothing" and "null" instead of "void", and we'd say like PHP
works, "return;" actually means "return null;", then:

function foo(): nothing {
return; // Error: cannot return null from a function that returns
nothing.
}
function bar(): null {
return;
// or return null;
}

This would more consistently tie into union types where |null is allowed,
however on its own it is not: "foo() : null => error".

As Levi said, this noreturn/never just perpetuates/amplifies the existing
void mistake and feels off, given that other recent changes to PHP have
been more bold, towards removing inconsistencies.


> Its said that composition is better than inheritance, so combining two
> behaviors into one keyword will be limiting in the future, if we think of
> other function flags that should compose with "never".
>
>
>> Cheers,
>> Aaron Piotrowski
>>
>>

Re: [PHP-DEV] [VOTE] noreturn type

[Benjamin Eberlei]

On Fri, Apr 2, 2021 at 3:14 AM Aaron Piotrowski  wrote:

>
> > On Apr 1, 2021, at 2:03 PM, Levi Morrison via internals <
> internals@lists.php.net> wrote:
> >
> > I do not care which name is chosen, but if we are going to have this
> > sort of thing in the language, it ought to be a bottom type, not an
> > attribute.
> >
>
> You make an excellent point Levi. I initially chose `noreturn` simply
> because I was familiar with the name from C and didn't have a strong
> opinion. However, I agree that `noreturn` is a poor choice for reuse as a
> bottom type, so I changed my vote to `never`.
>

i voted against this proposal, but changed my choice of "noreturn" to
"never", because it would ultimately be slightly less bad to have this name
for use as a bottom type. The name "never" is still unfortunate, because it
transmits "behavior" of being used in the context of a function, a better
name might have been "nothing" as Levi suggests.

But I again get to the point of the problem with this RFC due to naming.
"never" is actually combining "nothing" type with "noreturn" flag, so for
me the most consistent way would have been "public noreturn function foo():
nothing"

Its said that composition is better than inheritance, so combining two
behaviors into one keyword will be limiting in the future, if we think of
other function flags that should compose with "never".


> Cheers,
> Aaron Piotrowski
>
>

Re: [PHP-DEV] [VOTE] noreturn type

[Benjamin Eberlei]

On Thu, Apr 1, 2021 at 3:56 PM Andreas Leathley  wrote:

> On 01.04.21 10:56, Benjamin Eberlei wrote:
> > This RFC is using the declaration of the return type, to specify that it
> > never returns. As such noreturn or never is a keyword a long the lines of
> > public or final, but it is not a return type.
> >
> > I don't think the argument for potential optimizations in Opcache to
> > eliminate dead code or allow IDEs to hint at dead code are valuable
> enough
> > to justify this change.
>
> I already use @return no-return (supported by Psalm/PHPStan) in my code
> now, to clarify the code flow, and for me it fits perfectly for return
> types, as not returning is also a result of the function/method. Having
> a return type of "int" or "string" (or even "void") seems misleading
> when the method will never return anyway.
>
> noreturn/never might not be useful in all code, but for some parts like
> in a controller of a web application it makes handling redirects,
> authorization or 404 errors much easier, clearer and less error-prone,
> for example:
>
> ```php
> if (!isset($user)) {
>$this->notFound(); // this is a noreturn/never method
> }
>
> if (!$this->isGranted('adminPrivileges')) {
>$this->notAuthorized(); // this is a noreturn/never method
> }
> ```
>
> Adding noreturn/never on a language level would make sure calling
> "$this->notAuthorized();" never continues code flow. This is often also
> a security issue, as seen by an alternative way of handling the above
> use cases:
>
> ```php
> if (!isset($user)) {
>$this->notFound();
>return;
> }
>
> if (!$this->isGranted('adminPrivileges')) {
>$this->notAuthorized();
>return;
> }
> ```
>
> If you forget a return, suddenly you have issues. So even though
> noreturn/never is a niche language feature not everyone will use, it
> does address a very real use case.


I don't know, you are arguing that you forgot a return, but you also did
not forget to add a never return type. You
could easily fix this by inlining the exception instead.

```php
if (!isset($user)) {
   throw new NotFoundException();
}
```
Even when you insist on the function, it is a one liner that throws
immediately. Adding the never return type there isn't going to catch a
great many bugs.



> Using attributes has the disadvantage
> of not making the intent clear:
>

> ```php
> #[\NoReturn]
> function notAuthorized(): string
> {
>// Some code
> }
> ```
>
> Now you have a return type of string, but also the information that the
> function will never return anyway. That is confusing, but will be
> inevitable in some cases when implementing interfaces or an abstract
> class. In my opinion, the string return type is wrong in this case and
> can only mislead a developer.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] noreturn type

[Benjamin Eberlei]

On Tue, Mar 30, 2021 at 5:07 PM Matthew Brown 
wrote:

> Hey everyone!
>
> The vote for adding noreturn is now open:
>
> https://wiki.php.net/rfc/noreturn_type
>
> Voting will run through April 13th
>
> Best wishes,
>
> Matt and Ondrej
>

I voted no, because i think this should at the maximum be an attribute.

This RFC is using the declaration of the return type, to specify that it
never returns. As such noreturn or never is a keyword a long the lines of
public or final, but it is not a return type.

I don't think the argument for potential optimizations in Opcache to
eliminate dead code or allow IDEs to hint at dead code are valuable enough
to justify this change.

Re: [PHP-DEV] Built-in decorator attribute?

[Benjamin Eberlei]

On Sat, Mar 13, 2021 at 5:51 PM David Gebler  wrote:

> With the introduction of attributes in PHP 8, this new behaviour is still
> quite sparsely documented. Some of the articles I've seen out there,
> though, liken PHP's attributes to similar constructs in other languages
> including decorators in Python.
>
> Attributes are not the same thing as (Python's concept of) decorators and
> they shouldn't be confused; a decorator is a function which wraps another
> function and is automatically called in place of the wrapped function.
>
> This isn't currently possible in PHP. Using frameworks like Symfony, we can
> start to build things like this:
>
> class UserProfileController {
> #[LoginRequired]
> public function editProfile(...) { }
> }
>
> but the logic of enforcing our "require the user to be logged in" decorator
> relies on the surrounding framework controlling the flow of execution,
> reading the attribute and deciding whether to call the decorated method
> editProfile() at all.
>
> What we *can't* do is something like this:
>
> class Foo {
> private function timer(callable $wrapped)
> {
> $start = microtime(true);
> $wrapped();
> $end = microtime(true);
> $total = $end - $start;
> echo "Executed function in $total second(s)\n";
> }
>
>  #[timer]
> public function bar($a, $b) { ... }
>
> #[timer]
> public function baz($a, $b) { ... }
> }
>
> What I'm wondering is whether there's a desire / interest for a built-in
> attribute to provide this kind of behaviour modification.
>
> I'm thinking something like
>
> class Foo {
> private function timer(callable $wrapped) { ... }
>
> #[Decorator([self::class, 'timer'])]
> public function bar() {
> echo "Bar";
> }
> }
>
> Where this would result in any call to $foo->bar() being equivalent to as
> if the above were defined as:
>
> class Foo {
> private function timer(callable $wrapped) { ... }
>
>  public function __bar() {
> echo "Bar";
>  }
>
> public function bar() {
> return $this->timer([$this, '__bar']);
> }
> }
>
> I'm not saying I have the skills to implement this attribute (though I'd
> happily try), I'm not even in a position to propose a draft RFC at this
> stage, just throwing the idea out there to get a feel for what people think
> of the concept?
>

In my opinion it would be a fantastic addition to Core to be used by
application frameworks with "hook philosophies" that hack this
functionality on top of PHP with code generation or event dispatchers at
the moment (Magento 2, Drupal, Neos, Wordpress and so on) makes this a
potential future with wide adoption. If you'd get 2/3 votes for it is
another topic.

However, as functionality it could be provided as an extension first for a
proof of concept. The ingredients are all there, it doesn't need to be in
core:

1. Register an internal attribute, see my #[Deprecated] PR as an example
https://github.com/php/php-src/pull/6521

2. Register a zend_observer as a first step, that detects functions/methods
with a new #[Intercept] or whatever attribute you want and registers
observer callbacks. See ext/zend_test
https://github.com/php/php-src/blob/master/ext/zend_test/test.c or
tideways/php-xhprof-extension:
https://github.com/tideways/php-xhprof-extension/blob/master/tideways_xhprof.c#L30-L57

3. Use C API zend_call_function in the observer to call your interceptor.

Cobbling this together as a Frankestein monster from existing code should
be achievable even if you haven't worked with PHP core yet imho. This could
replace the php-aop extension that isn't maintained anymore.

Using a zend_obserer would only allow you to register a before and after
hook, the alternative with a "$wrapped()" would be significantly more
complex with the existing building blocks.

Hooking into zend_exeute_ex would allow you to implement around handling,
but at this point is not recommended anymore, because its incompatible with
JIT and might be removed in the future.


>
> Regards,
> Dave
>

Re: [PHP-DEV] [VOTE] Fibers

[Benjamin Eberlei]

On Wed, Mar 10, 2021 at 10:51 PM Kalle Sommer Nielsen  wrote:

> Den ons. 10. mar. 2021 kl. 20.22 skrev Dan Ackroyd  >:
> >
> > Hi internals,
> >
> > Well, technically this is addressed more to people who read internals.
> >
> > Please don't contact people off list putting pressure on them to vote
> > in a particular way.
> >
> > It _really_ is not appreciated, no matter how well intentioned the
> > sender thinks it is.
>
> For the sake of integrity, I believe the vote should be halted and
> restarted at a later date to prevent the influence of referenced email
> from having a favored vote. This has no relation to my personal vote
> on the matter of the RFC however.
>

If the email was sent by the RFC authors itself I would agree, but it was
not.

Stopping the vote because of this would provide precedent to bombard any
RFC vote by just emailing all voters a nasty email.

>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] New in initializers

[Benjamin Eberlei]

This is

On Wed, Mar 3, 2021 at 4:04 PM Nikita Popov  wrote:

> Hi internals,
>
> I would like to propose allowing the use of "new" inside various
> initializer expressions: https://wiki.php.net/rfc/new_in_initializers
>
> In particular, this allows specifying object default values for properties
> and parameters, and allows the use of objects as attribute arguments.
>

This is the missing puzzle piece that i imagined would be needed for nested
attributes. This is really awesome!

I look forward to going over the patch to see how it works, specially since
Martin's and my attempts failed to break through last year for Attributes :)


> The RFC is narrow in scope in that it only adds support for "new". An
> extension to other call kinds should be straightforward though.
>
> Regards,
> Nikita
>

Re: [PHP-DEV] [RFC]: Change Default mysqli Error Mode

[Benjamin Eberlei]

On Sat, Feb 27, 2021 at 5:24 PM Kamil Tekiela  wrote:

> >
> > The issue is, as said, that this only happens in an error situation.
> > Thus if users only test "does my site still work after update?" (what
> > many do ...) won't notice this, till something fails, which would have
> > been caught nice beforehand.
> >
>
> I don't see why this would be such an issue. If the code fails for any
> reason then an error is produced. The error might be surprising, but it is
> not something that would cause problems.
>

I think you are very wrong about this, there could be perfectly valid code
doing:

if (!$conn->query("select 1") && $conn->errno == 2006) { // mysql gone away
$conn = new mysqli();
}

With your proposed change the query would throw an exception instead,
potentially breaking follow up code that is required to run.

This is the kind of code you have that only gets triggered every 10
times and that is very hard to write a real test for. If the test here uses
a mock, then you wont catch the behavior change.


> This change fixes more problems than it creates. I believe it is still
> worthy to put it in 8.1.  Every PHP release contains backwards-incompatible
> changes. In comparison to other BC changes PHP has put in minor releases
> this one has a very easy fix. You don't have to scour the code looking for
> places to fix.
>

There are projects out there that do a mysqli_connect on *every* script.
You underestimate the impact of this break.

PHP can't improve if we have to think of people who upgrade without reading
> the release notes. We also shouldn't be held back by outdated tutorials. In
> fact, this will help people who still use such tutorials. This isn't a
> major change that would affect everyone on the planet. This will only
> affect people who still use mysqli and didn't set the error reporting mode
> before upgrading.
>

I am sorry, but to me that feels a bit like you want to take the easy way
out..

As a counterexample, Nikita made a very good RFC for 8.1 / 9.0 deprecating
and changing the nullable to internal functions behavior:
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg

This RFC goes above and beyond to provide a migration path, deprecation
messages and such.

Yes it has a higher potential break impact, but i don't expect this change
to wait until 9.0 either.

I would wish your RFC would throw a deprecation message in 8.1 that you
cannot make a query without setting the reporting level before by calling
mysqil_report() explicitly. Then in 8.2 we could change the behavior.


> I understand your worries but I don't think this is a good enough reason to
> not go ahead with this change.
>
> Kind regards,
> Kamil
>

Re: [PHP-DEV] [VOTE]: Change Default mysqli Error Mode

[Benjamin Eberlei]

On Thu, Feb 11, 2021 at 12:36 AM Kamil Tekiela  wrote:

> Hi internals,
>
> I have started voting on https://wiki.php.net/rfc/mysqli_default_errmode
> The voting period is 2020-02-11 -- 2020-02-28
>

While the change in itself is something I want to see, I voted no on this
proposal because its a BC break that will break a lot of software out there
and there is no attempt at deprecating the old way and guiding users to the
new behavior.

I wish this would be more gradual by requiring the reporting setting in the
constructor, throwing a deprecation warning when none is provided and then
changing this behavior in 9.0

>
> Kind Regards,
> Kamil
>

Re: [PHP-DEV] [RFC] Fibers

[Benjamin Eberlei]

On Thu, Dec 17, 2020 at 5:30 PM Aaron Piotrowski  wrote:

> Hello everyone!
>
> I would like to introduce an RFC for adding full-stack fibers to PHP:
> https://wiki.php.net/rfc/fibers
>
> Fibers are primarily used to implement green-threads or coroutines for
> asynchronous I/O. Fibers are similar to threads, except fibers exist within
> a single thread and require cooperative scheduling of the fibers by the
> process. Since fibers do not require a full CPU context switch, they are
> lightweight and more performant than multi-processing or threading for
> awaiting I/O.
>
> An implementation as an extension is at https://github.com/amphp/ext-fiber
>
> Fibers are a complex feature. The RFC contains many examples and links to
> code using fibers to help explain and demonstrate what is possible, however
> I’m certain many more questions and concerns will arise. Looking forward to
> feedback and discussion.
>
> Aaron Piotrowski
>

Hi Aaron,

this is a very interesting and welcome piece of functionality. I have gone
through the RFC a few times now, it have never thought about or worked with
fibers before, additional feedback will be forthcoming once I grasp the
details more.

>From my POV the effects on other extensions are the most important factor,
you already have a section with that for Xdebug, Parallel, and pcov. But
how does this affect Profilers that manage their own stack of frames,
either all function calls or specifically selected ones. I.e. xhprof,
tideways, datadog, newrelic and so on.

At the moment any PHP Profiler only has to manage a single stack of "open
frames". With Fibers for each fiber a new stack must be opened.

Does an extension know what the "active" fiber is so that  from a
zend_execute_data I know on which stack of open frames I need to push a new
frame?

Could you add a section to the RFC explaining how a switch between fibers
works in terms of "the next" and "previous" zend_execute_data that is run?
This  would also be interesting to understand how stack traces work, for
example debug_print_backtrace.


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

Re: [PHP-DEV] #[Deprecated] Attribute

[Benjamin Eberlei]

On Wed, Jan 13, 2021 at 1:34 PM Marco Pivetta  wrote:

> On Sun, Jan 10, 2021 at 2:48 AM G. P. B.  wrote:
>
>> Just to clarify this raises an E_DEPRECATED right?
>> Could it make sense to raise E_USER_DEPRECATED instead?
>>
>
> I hadn't checked this before, but as per George's message, this is
> worrying.
>
> I've been quite loud about it in the past, but static metadata definitions
> should really not lead to runtime side-effects, especially if not pure
> (error handling system tripped here).
>
> I'd be totally for a built-in `#[Deprecated]` attribute if it did **NOT**
> have a runtime behavior, which is an absolute no-go from my PoV.
>
> This stuff is easily introspectible via tools like phpstan, psalm, phan,
> and does not need to lead to more problematic runtime issues.
>

I get where you are coming from, but side-effect based notices/deprecations
is just the way PHP works at the moment and as such this existing mechanism
should be used and extended.

I do have (vague) plans to tackle alternative ways to process
notices/deprecations in the future, but this is independent from that and
#[Deprecated] would automatically tie into a change of this kind.

>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

Re: [PHP-DEV] #[Deprecated] Attribute

[Benjamin Eberlei]

On Wed, Jan 13, 2021 at 1:05 PM Brent Roose  wrote:

> Hi Sara
>
> > On 22 Dec 2020, at 19:54, Sara Golemon  wrote:
> >
> > On Tue, Dec 22, 2020 at 12:35 PM Nicolas Grekas <
> > nicolas.grekas+...@gmail.com> wrote:
> >
> >> It would be great to allow adding this attribute on classes. What about
> >> allowing it right now and not bind it to any runtime side-effect? That
> >> would allow static analyzers to do their job. Same for consts and
> >> properties by the way.
> >>
> >> Also, it would be very useful to add named parameters to the attribute,
> >> namely: "package" (the name of the package that declares the
> deprecation)
> >> and "version" (the version of that package that introduced the
> >> deprecation), next to the message.
> >>
> >> This is critical info when building reports of deprecations.
> >>
> >>
> > You could do that now with a polyfill from userspace.  If the annotation
> > need not have an effect, then it's just any other userspace
> implementation.
>
> The difference is that PHP core has the ability to force standarization.
> There's already JetBrains' implementation of #[Deprecated], which Psalm and
> PhpStan also support, but it's not a real standard. Maybe the FIG would one
> day step in to decide these kinds of things, but the reality is that many
> major frameworks don't follow FIG as closely as they used to. I think
> there's value in adding attributes in the core, with the goal only being
> static analysis. It'll allow for consistency and that's a valuable thing.
>

I want to keep #[Deprecated] on other elements than functions / methods out
of this RFC, because they require entirely different implementation
approaches.

We identified in the PR already that this should at some point be
standardized in core, because internal attributes will currently not be
able to support extension through inheritance by userland for
implementation reasons.

My next RFC update will reflect this future scope.

>
> >
> > -Sara
>
>
> Kind regards
> Brent
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Enumerations, Round 2

[Benjamin Eberlei]

On Mon, Dec 28, 2020 at 9:22 PM Larry Garfield 
wrote:

> Hello, Internalians!
>
> After considerable discussion and effort, Ilija and I are ready to offer
> you round 2 on enumerations.  This is in the spirit of the previous
> discussion, but based on that discussion a great deal has been reworked.
> The main change is that Enumeration Cases are now object instances of the
> Enumeration class rather than their own class.  Most of the other changes
> are knock-on effects of that.
>
> Of particular note:
>
> * Cases may not have methods or constants on them.  They're just dumb
> values.
> * Enums themselves may have methods, static methods, or constants.
> * Traits are supported, as long as they don't have properties.
> * The value() method on scalar enums is now a property.
>
> The full RFC is here, and I recommend reading it again in full given how
> much was updated.
>
> https://wiki.php.net/rfc/enumerations
>
> The implementation is 98% complete; there's still a few lagging bits in
> reflection, and some opcache bugs that Ilija is still stomping on.
>
> There are a few outstanding questions listed that we would like feedback
> on.  We're not entirely certain which direction to go with them, for
> reasons explained in the RFC.  Input on those is especially welcome.
>
> Happy New Year.  May it be enumerable.
>

I think the reflection part is the weakest of this proposal, in my opinion
there should not be a ReflectionEnum and ReflectionCase.

- ReflectionEnum extends ReflectionClass is problematic
- is hasEnum just an alias for hasConstant?
- Same for getCases() for getConstants().
- what does getConstant() or ReflectionClassConstant::getValue return for a
non scalar enum? the instance?

In my opinion you should embrace the "desugarizing" like constructor
promotion and just keep everything with the exsiting Reflection structure.

>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] #[NamedParameterAlias] Attribute

[Benjamin Eberlei]

On Sat, Dec 19, 2020 at 8:27 PM Rowan Tommins 
wrote:

> On 19/12/2020 11:28, Benjamin Eberlei wrote:
> > This is my take on parameter names now being public API, at its future
> > potential for code maintenance, refactoring and backwards compatibility.
> >
> > https://wiki.php.net/rfc/named_parameter_alias_attribute
>
>
> Hi Benjamin,
>
> This sounds like a sensible feature. The suggested name seems a bit
> long, but I'm not quite sure what to replace it with.
>
> It just occurred to me that there's a potential connection, in concept
> if not implementation, with the #[Deprecated] RFC you also just posted:
> parameter name aliases may well be used to provide a limited-time
> transition mechanism rather than a permanent feature, so it might be
> useful to allow them to be marked as deprecated.
>
> e.g.
>
> // Version 1.0: parameter name is misspelled
> function doSomething(bool $formatNumters) { ... }
>
> // Version 1.1: parameter name changed, old name added as a deprecated
> alias
> // if the misspelled name is used, an E_DEPRECATED is raised
> function doSomething(#[ParameterNameAlias('formatNumters', deprecated:
> true)] $formatNumbers) { ... }
>
> // Version 2.0: alias removed; the misspelled name is now an error
> function doSomething(#[ParameterNameAlias($formatNumbers) { ... }
>

Oh that is a great idea! It makes sense to allow developers to mark the
alias as the deprecated parameter name. I will add this to the RFC on my
next iteration.

>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] [RFC] #[NamedParameterAlias] Attribute

[Benjamin Eberlei]

Hi internals,

another RFC using attributes for 8.1. The patch itself for this is really
small, but the implications require a detailed discussion and scrutiny.

This is my take on parameter names now being public API, at its future
potential for code maintenance, refactoring and backwards compatibility.
There might be other approaches that I am unaware of that would be better.

This feature will probably also be helpful to allow more work on improving
named params API of internal/core APIs, as the time period between named
params RFC and 8.0 release was rather short and we might find that we want
to further improve the names of internal parameters.

https://wiki.php.net/rfc/named_parameter_alias_attribute
https://github.com/php/php-src/pull/6522

Looking forward to your feedback.

greetings
Benjamin

[PHP-DEV] #[Deprecated] Attribute

[Benjamin Eberlei]

Hi internals,

I have updated the RFC for a #[Deprecated] attribute that wasn't completed
for PHP 8.0 due to time constraints and I am able to restart the discussion
now.

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

The following updates have been made:

- focus on only method and function deprecations for now, removed
class/property/constant deprecations.
- a section on explaining the runtime effects of deprecations in PHP, and a
note that this RFC is about completing deprecation support within the
existing model, while changes to deprecations in general are out of scope /
a disjunct concern for a different RFC.

Sara proposed a much improved implementation over my initial patch, by
using the already existing ZEND_ACC_DEPRECATED constant on userland
functions. The resulting implementation is therefore much simpler and
really just extending existing function deprecation support from internal
to userland functions. You can find the PR here:

https://github.com/php/php-src/pull/6521

Let me know what you think.

greetings
Benjamin

Re: [PHP-DEV] [RFC] [Discussion] Measuring maximum execution time based on wall-time

[Benjamin Eberlei]

Hi Máté

we talked about this before and I think it's a good addition. Two
suggestions to improve the RFC:

The RFC could include more details on how the behavior works exactly in
combination with long running I/O. Lets say the default socket timeout
being 60 seconds, andt the max execution wall time being 10 seconds. What
happens if an HTTP call taking 60 seconds via file_get_contents gets
started at 9 seconds in the request?

I think you should mention that you also need to configure the timeouts of
all I/O operations for an effective strategy, so that one gets a good
picture how this puzzle piece fits into production.

greetings
Benjamin





On Sun, Dec 13, 2020 at 1:25 AM Máté Kocsis  wrote:

> Hi Everyone,
>
> Thanks for all the insightful feedbacks so far, I went ahead, and wrote a
> proper
> RFC: https://wiki.php.net/rfc/max_execution_wall_time
>
> Regards:
> Máté
>

Re: [PHP-DEV] PHP 8 release announcement page on php.net

[Benjamin Eberlei]

On Wed, Oct 14, 2020 at 1:56 AM tyson andre 
wrote:

> Hi internals,
>
> > As far as php.net can help with PHP's reputation, I think a brief
> homepage
> > intro that showcased some modern-looking PHP code would be great (e.g.
> > typescriptlang.org, golang.org). The docs design could also be
> > slightly tweaked to make everything seem newer, while still keeping the
> > (very good) content basically the same.
>
> That reminds me of an idea I had a while ago:
> One of the features I've seen on many other programming
> languages' documentation and tutorials was the ability to run and edit the
> example snippets.
> It may help in understanding the content of tutorials or example snippets
> for functions,
> - e.g. seeing what happens if code is rearranged
>   or how PHP handles edge cases
> - It also allows new developers to try out php before deciding to install
> it.
>
> Right now, you can read the examples in
> https://www.php.net/manual/en/language.variables.scope.php
> and copy them to run them locally, but you can't run them and see their
> output
> (as plain text or html, depending on context)
>
> Some examples in other languages:
>
> - MDN has JavaScript demos in the browser, e.g.
>
> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/some
> - Rust has https://play.rust-lang.org/ (run on the server side)
> - golang has https://tour.golang.org/welcome/1 (run on the server side)
>
> There's two main options available for testing out php in a browser right
> now:
>
> - A general sandboxed php implementation hosted by the owners of php.net
>   (requires that it be secured and may lead to additional hosting costs),
>   https://3v4l.org/ (not open source https://3v4l.org/about - but similar
> to what I was thinking of)
>   or https://psalm.dev/ (open source) are projects in that area
>   (Matthew Brown is one of the authors of Psalm)
> - A WebAssembly solution, e.g. https://phan.github.io/demo/ (forked from
> https://oraoto.github.io/pib/)
>   (I'm one of the maintainers of Phan)
>
> WebAssembly has some noticeable drawbacks such as requiring a modern
> browser,
> requiring a large download, and requiring more RAM than an ordinary
> website.
> Many other websites for programming languages have moved to sandboxed
> implementations
> hosted on an actual server.
>
> Thanks,
> - Tyson
>

Sorry to step in here as this crowds out the original post too much imho,
this is really a tangential concern from Romans original post though.
Inline execution would be really awesome, but coupling this to a release
announcement to PHP 8 sets both projects up for failure imho.

To expand back to the topic, if we think Romans idea is great, then the
next steps would be to enable Roman to put this in place for the PHP 8
release. Its only 6 few weeks out, so going this backwards i would say

1. October: RMs and/or php-web maintainers should give their go on the idea
(someone else?), so that more detailed creative time investment is not
going to waste.
2. until mid November: Roman's group of contributors have time to finalize
creative design and copywirting
3. until mid November Someone with access to php-web would volunteer to
guide through technical roadblocks / deployment of the release
announcement, maybe keeping it simple as a static html page for now
4. ~20th November: Page is rolled out with a date based feature flag?


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

Re: [PHP-DEV] PHP 8 release announcement page on php.net

[Benjamin Eberlei]

Hi Roman,

On Mon, Oct 12, 2020 at 9:57 AM Roman Pronskiy 
wrote:

> Hello Internals,
>
> The PHP 8 release is going to be huge, and in some sense, you could
> say it's a whole new language. There is a feeling that more can be
> done to promote it more extensively.
>
> Usually for releases, there’s a short text announcement on php.net.
> This may be okay for minor releases and for people who are deeply
> involved in PHP as they already know about the new features. But for
> the majority of PHP developers and potential PHP developers, it is not
> enough.
>
> So, the idea is to create a separate release announcement landing page
> to achieve the following goals:
>
> – Promote the release of PHP 8 to the PHP developers
> – Promote PHP as a modern language, as well as the PHP 8 release, to
> the general tech audience
>
> Alexander Makarov, myself, and Svetlana Belozerova, a designer from
> JetBrains, have created the following concept:
> https://i.imgur.com/6fKmTyM.jpg
>
> We’d like to hear from you about how you like the idea. If you support
> it, we’ll finish the design and work on a PR against
> github.com/php/web-php with the implementation.
>
> Looking forward to hearing what you think.
>

i love the idea!

Honestly in my opinion, the actual content itself and what is or what is
not on the page is not so important, this kind of release announcement post
is mostly about the signal effect to the outside world that there is a
force behind PHP that goes beyond "a few people tinkering on a programming
language" (to be hyperbolic). As such I think we should just do it and not
bikeshed over the content, or if this marketing speaks to old or new users
or what does. If the overall message is along the lines is "PHP gets faster
again, PHP gets more awesome features again, PHP is alive and kicking" then
this is a huge win :-)

>
> Roman Pronskiy,
> PMM at JetBrains
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Attributes and constructor property promotion

[Benjamin Eberlei]

On Tue, Oct 6, 2020 at 6:21 PM Andreas Leathley  wrote:

> On 06.10.20 17:15, Sara Golemon wrote:
> > My opinion on constructor property promotion (CPP) is that it's something
> > for small value object classes and should probably be regarded as
> > code-smell on larger classes. At the same time, annotations belong with
> > more complex objects and not so much with small "struct-like" classes.
> >
> > Given that position, I think we should err towards strictness in how
> > attributes are applied to CPP declarations.  That is, we should require
> > them to be meaningfully applicable to both arguments and properties in
> > order to be used in a CPP context.  If that's a problem for the consumer,
> > then they should avoid use of CPP.
> >
> > -Sara
>
> The current usage of annotations is quite often with small struct-like
> classes though - I mainly use annotations (and will use attributes) for
> data that needs to be validated, or entity-like classes that contain
> data. Those classes are small and simple and would benefit greatly from
> CPP and attributes used in combination, so it would be a pity to make
> that impossible.
>
>  From my understanding suppressing the validation errors in this
> particular case would be a good solution, or are there any serious
> downsides to that?
>

This is my argument as well. Attributes + CPP are a powerful combination.

Attributes are an important use-csae for data transfer objects, to
configure validation or serialization for example:

class ChangeFirstNameRequest
{
public function __construct(
#[Validate\IsPositive]
public int $id;
#[Validate\NotBlank]
#[Json("first_name")]
 public string $firstName;
) {}
}


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

Re: [PHP-DEV] Re: Attributes and constructor property promotion

[Benjamin Eberlei]

On Tue, Sep 29, 2020 at 3:45 PM Larry Garfield 
wrote:

> On Mon, Sep 28, 2020, at 12:06 PM, Benjamin Eberlei wrote:
> > On Mon, Sep 28, 2020 at 4:35 PM Benjamin Morel  >
> > wrote:
> >
> > > On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas <
> nicolas.grekas+...@gmail.com>
> > > wrote:
> > >
> > >> I assume the 80% case is properties, because attributes did not have
> > >>> docblock annotations yet, that means this use-case isn't even
> possible at
> > >>> the moment. Yet annotations on properties are widespread (Doctrine
> ORM,
> > >>> symfony validator, ...).
> > >>>
> > >>
> > >> I'm 100% with Benjamin here, this is what will be the most useful to
> me
> > >> also.
> > >>
> > >
> > > To be clear, I don't have a strong opinion against yours, I'm just
> > > pointing out the fact that even though it might be useful, it might
> also be
> > > confusing and create yet another WTF moment in PHP for developers.
> Sure, it
> > > might make more sense to apply to the property. Sure, so far
> annotations
> > > weren't possible on parameters. But is that obvious to the average
> > > developer writing the attribute? A few years down the road, DI
> containers
> > > may have broad support for annotating parameters for injection. Will it
> > > still be obvious then that an attribute on a promoted property applies
> to
> > > the property only?
> > >
> > > I do agree that applying the attribute to both the property and the
> > > parameter will probably never be useful, though. So, throwing an
> exception
> > > and forcing the de-sugaring feels like the most sensible thing to do
> for me
> > > in this case!
> > >
> >
> > I haven't checked if this is possible in the code doing the "desugering",
> > but what if we had an attribute on the constructor that could specify
> where
> > the attributes should apply to?
> >
> > #[AttributePromotion(Attribute::TARGET_PROPERTY)]
> > public function __construct(#[Foo] public string $bar) {}
> >
> > Then we could apply it to both by default, which is what is probably the
> > expected approach, and users could change it to apply only to properties,
> > which is what is the use-case that makes most sense.
> >
> > >
> > > — Benjamin
>
> From a user experience POV, I'd almost expect the opposite.
>
> If I mark the attribute as being for properties, it gets applied to the
> property.
>
> If I mark the attribute as being for parameters, it gets applied to the
> parameter.
>
> If I mark it for both, or don't restrict it at all, it applies to both.
>
> That may not be how the logic is currently implemented but that's what as
> a user I'd find least-surprising.
>

The problem with this approach is that it would require autoloading the
attributes when they are assigned to either the internal property or
parameter struct, but we have the design goal *not* to trigger autoloading
unless newInstance() or getArguments() is called. What you could do in
userland code is handle this case yourself and never newInstance()
attributes that don't apply to the right "thing" (parameter vs property).
but that would defer the problem to userland with some annoying piece of
code.


> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] List of attributes

[Benjamin Eberlei]

On Mon, Sep 28, 2020 at 2:58 PM Nicolas Grekas 
wrote:

>
> Hi Benjamin, hi everyone
>>>
>>> I'm wondering if the syntax that allows for several attributes is really
>>> future-proof when considering nested attributes:
>>>
>>>
>>> *1.*
>>> #[foo]
>>> #[bar]
>>>
>>> VS
>>>
>>>
>>> *2.*
>>> #[foo, bar]
>>>
>>> Add nested attributes to the mix, here are two possible ways:
>>>
>>>
>>> *A.*
>>> #[foo(
>>> #[bar]
>>> )]
>>>
>>> or
>>>
>>>
>>> *B.*
>>> #[foo(
>>> bar
>>> )]
>>>
>>> The A. syntax is consistent with the 1. list.
>>> I feel like syntax B is not desired and could be confusing from a grammar
>>> pov.
>>> BUT in syntax 2., we allow an attribute to be unprefixed (bar), so that
>>> syntax B is consistent with 2.
>>>
>>> Shouldn't we remove syntax 2. in 8.0 and consider it again when nested
>>> attributes are introduced?
>>>
>>> I voted yes for syntax 2. when the attributes were using << >>. I would
>>> vote NO now with the new syntax.
>>>
>>> Nicolas
>>>
>>
>> As far as my understanding goes, if we introduce "nested" attributes, it
>> will be in the form of relaxing constraints on constant expressions, i.e.
>> by allowing you to write #[Attr(new NestedAttr)].
>>
>
> That's what I've read in previous discussions and in other replies in this
> thread.
> This would break the possibility to read annotations without failing hard
> when a class is missing.
>
> I would much prefer a solution that preserves this capability (which is
> the reason why we have ReflectionAttribute::newInstance(): unless this one
> is called, no autoloading happens.
>
> To me, this means that "new Foo()" nested in an attribute can't be a
> solution.
> Neither should we be able to nest PHP constants there btw.
>

Can you clarify your reasoning here to get to this conclusion? because with
#[Foo(Foo::BAR)] we also not trigger autoloading right now until
newInstance()
or getArguments() is called. This is the way it is working right now:
https://gist.github.com/beberlei/8150f60abaab3b0a70ebb76ce6a379b0

Attributes allow constant expressions as arguments, the same which you can
do in constant or property declarations for the default value.

An approach with new NestedAttr() would work the same, only triggering
autoload when argument needs to be evaluated for use.

>
> Since we borrowed the syntax to Rust, here is the syntax they use:
>
> > #[validate(length(min = 1), custom = "validate_unique_username")]
>
> I think this would fit quite nicely for us too, by turning eg length into
> an instance of ReflectionAttribute.
>
> Note that a use case for nested attributes is discussed in
> https://github.com/symfony/symfony/pull/38309, to replace things like:
> /**
> @Assert\All([
> @Assert\Email,
> @Assert\NotBlank,
> @Assert\Length(max=100)
> ])
> */
>
> We can work around of course, and we will for 8.0, but it would be nice to
> have a plan forward because similar use cases (grouping attributes in a
> wrapper attribute) are going to be pretty common IMHO.
>
> But we're getting a bit of topic. I'm fine keeping things as is for 8.0. I
> just wanted to raise a point about the syntax for list of attributes but it
> didn't get traction apparently.
>
> Cheers,
> Nicolas
>

Re: [PHP-DEV] Re: Attributes and constructor property promotion

[Benjamin Eberlei]

On Mon, Sep 28, 2020 at 4:35 PM Benjamin Morel 
wrote:

> On Mon, 28 Sep 2020 at 15:17, Nicolas Grekas 
> wrote:
>
>> I assume the 80% case is properties, because attributes did not have
>>> docblock annotations yet, that means this use-case isn't even possible at
>>> the moment. Yet annotations on properties are widespread (Doctrine ORM,
>>> symfony validator, ...).
>>>
>>
>> I'm 100% with Benjamin here, this is what will be the most useful to me
>> also.
>>
>
> To be clear, I don't have a strong opinion against yours, I'm just
> pointing out the fact that even though it might be useful, it might also be
> confusing and create yet another WTF moment in PHP for developers. Sure, it
> might make more sense to apply to the property. Sure, so far annotations
> weren't possible on parameters. But is that obvious to the average
> developer writing the attribute? A few years down the road, DI containers
> may have broad support for annotating parameters for injection. Will it
> still be obvious then that an attribute on a promoted property applies to
> the property only?
>
> I do agree that applying the attribute to both the property and the
> parameter will probably never be useful, though. So, throwing an exception
> and forcing the de-sugaring feels like the most sensible thing to do for me
> in this case!
>

I haven't checked if this is possible in the code doing the "desugering",
but what if we had an attribute on the constructor that could specify where
the attributes should apply to?

#[AttributePromotion(Attribute::TARGET_PROPERTY)]
public function __construct(#[Foo] public string $bar) {}

Then we could apply it to both by default, which is what is probably the
expected approach, and users could change it to apply only to properties,
which is what is the use-case that makes most sense.

>
> — Benjamin
>

Re: [PHP-DEV] Re: Attributes and constructor property promotion

[Benjamin Eberlei]

On Mon, Sep 28, 2020 at 2:25 PM Benjamin Morel 
wrote:

>   On Mon, 28 Sep 2020 at 13:56, Benjamin Eberlei 
> wrote:
>
>
>> imho, we should pick the 80% use-case and advise to desugar the code if
>> other behavior is desired. For me the 80% case is that the attribute only
>> applies to the property, not to the parameter.
>
>
> +1 for the desugaring advice in this case, however as a matter of
> consistency I'd rather have it either apply to both the property and the
> parameter, or just throw an exception if used on promoted properties,
> whatever the 80% use-case is (source?)
>

We should assume that there are very few attributes that make sense to
apply to *both* a property and an argument. I can't find any good example
where this makes sense.

Library developers shouldn't be forced to allow target argument only that
it works in the ctor promotion case.

I assume the 80% case is properties, because attributes did not have
docblock annotations yet, that means this use-case isn't even possible at
the moment. Yet annotations on properties are widespread (Doctrine ORM,
symfony validator, ...).


> Kind regards,
> — Benjamin
>

[PHP-DEV] Re: Attributes and constructor property promotion

[Benjamin Eberlei]

On Mon, Sep 28, 2020 at 12:36 PM Nikita Popov  wrote:

> Hi internals,
>
> When the constructor property promotion landed, the question of how it
> interacts with attributes on promoted properties did not get fully
> resolved. See https://wiki.php.net/rfc/constructor_promotion#attributes
> for what the issue is.
>
> The behavior that landed was to apply the attribute is applied to both the
> parameter and the property. However, this was with the understanding that
> we may have to adjust the behavior later, in particular depending on how
> the whole "attribute target validation" turns out. The way it is now, using
> a property-only attribute on a promoted parameter may result in spurious
> validation errors.
>
> I wanted to bring up this topic now to make sure it's not forgotten... I
> still don't really know what the best behavior here is.
>

imho, we should pick the 80% use-case and advise to desugar the code if
other behavior is desired. For me the 80% case is that the attribute only
applies to the property, not to the parameter.

>
> Regards,
> Nikita
>

[PHP-DEV] Re: List of attributes

[Benjamin Eberlei]

On Sun, Sep 27, 2020 at 10:23 AM Nicolas Grekas 
wrote:

> Hi Benjamin, hi everyone
>
> I'm wondering if the syntax that allows for several attributes is really
> future-proof when considering nested attributes:
>

I feel this question is what an RFC for nested attributes has to weigh. We
have established that in practice nested is possible syntax wise.
Personally I am not interested in introducing nested attributes, because
they would allow a complexity in attribute usage that might be better
handled by actual configuration files (XML, JSON, YAML, INI choose your
poison).

As such I am not looking into working on this addition myself and haven't
put any thought into the actual syntax.

In general we have not established yet if the support for nested attributes
would get a super majority of voters and its increased complexity is the
major reason why I opted to leave it out of the original RFC.

For Doctrine ORM for example I prototyped this new attribute based driver
that flattens the structure so that nested attributes are not needed
https://github.com/doctrine/orm/pull/8266 - without making the usage less
clear (in my opinion).

>
>
> *1.*
> #[foo]
> #[bar]
>
> VS
>
>
> *2.*
> #[foo, bar]
>
> Add nested attributes to the mix, here are two possible ways:
>
>
> *A.*
> #[foo(
> #[bar]
> )]
>
> or
>
>
> *B.*
> #[foo(
> bar
> )]
>

I'll throw a few more options into the mix

- #[foo(bar())]
- #[foo(#bar())]
- #[foo(new bar())]


> The A. syntax is consistent with the 1. list.
> I feel like syntax B is not desired and could be confusing from a grammar
> pov.
> BUT in syntax 2., we allow an attribute to be unprefixed (bar), so that
> syntax B is consistent with 2.
>
> Shouldn't we remove syntax 2. in 8.0 and consider it again when nested
> attributes are introduced?
>
> I voted yes for syntax 2. when the attributes were using << >>. I would
> vote NO now with the new syntax.
>
> Nicolas
>

Re: [PHP-DEV] PHP 8.0 branch cut

[Benjamin Eberlei]

On Tue, Sep 15, 2020 at 8:20 AM Brent Roose  wrote:

> Hey Dmitiry
>
> Speaking of the JIT. I remember berblei mentioning that the JIT
> configuration options were going to change prior to the final 8 release (
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/
> <
> https://www.reddit.com/r/PHP/comments/hjxlh9/jit_benchmarks_on_reallife_web_applications/fwuje8g/>).
> In other words: not one value with several integer flags, but dedicated
> options for every configuration entry. Is this still on the roadmap?
>

 Hi Brent, Hi Sebastian,

this is already done by this PR https://github.com/php/php-src/pull/5913

The options to talk about and use in docs/posts are the following:

opcache.jit=yes|true|1
opcache.jit=tracing
opcache.jit=function

These differentiate the Tracing-JIT from the Function-JIT. Default is
tracing.

>
> Kind regards
> Brent
>
> > On 15 Sep 2020, at 07:05, Dmitry Stogov  wrote:
> >
> > This also gives me a time frame to clean up JIT code without hurry.
> > I plan to separate the common JIT code, and merge JIT and VM helpers.
> >
> > Thanks. Dmitry.
> >
> > On Mon, Sep 14, 2020 at 5:55 PM Sara Golemon  wrote:
> >
> >> On Mon, Sep 14, 2020 at 9:39 AM Nikita Popov 
> wrote:
> >>
> >>> On Fri, Sep 11, 2020 at 6:49 PM Sara Golemon  wrote:
> >>>
>  Next Tuesday, Sep 15th, has been marked on my calendar as the branch
> >> date
>  for PHP-8.0 which would open master up for 8.1 targeted work.
> 
>  This would mean that bug fixes would need to include PHP-8.0 in their
>  merge
>  chain (meaning more work to merge 8.0 targeted fixes).
> 
>  Please let Gabriel and I know how you feel about this date.  I can see
>  that
>  master is still quite active, and I don't wish to make the work to
>  stablize
>  the 8.0 release any more difficult than it has to be.
> 
> 
> >>>
> >>> I think it would be good to make this week's release beta4 rather than
> >> rc1
> >>> (without affecting the rest of the schedule). In that case we'd also
> push
> >>> back the branching and final ABI freeze two weeks.
> >>>
> >>> We're close to done with the warning to Error exception promotion task,
> >>> but haven't really started on reviewing and consolidating parameter
> names
> >>> yet (in preparation for named parameters). It would be good to have
> that
> >>> work mostly finalized before RC1, so we can limit the number of
> nominally
> >>> BC-breaking changes past RC1 (I expect we'll still fix some things that
> >>> slipped through the cracks, but at least we should prevent any mass
> >>> changes).
> >>>
> >>>
> >> Yep. This seems like a reasonable adjustment to the schedule in order to
> >> finalize these features.  I'll do beta4 tomorrow/thursday, and we should
> >> plan for RC1 branching in two weeks.  Wiki (
> >> https://wiki.php.net/todo/php80 )
> >> has been updated to reflect this.  Note that I have NOT moved the GA
> date
> >> at this time, as that would push us into Dec 10th.  Though as the date
> >> approaches we may decide to add RC5 back in for safety despite the
> >> perinavidinal timing.
> >>
> >> -Sara
> >>
> >> P.S. Yes, I made that word up. You know which one.
> >>
>
>

Re: [PHP-DEV] Add interface implementation to class in separate file

[Benjamin Eberlei]

On Sat, Sep 12, 2020 at 10:23 PM Olle Härstedt 
wrote:

> Hi internals!
>
> Separation of data and behaviour is both a fun and hard discussion,
> especially considering:
>
> * "It should be possible to add new features without touching old code";
> and
> * "Principle of Least Privilege" (never expose more than you have to)
> (https://en.wikipedia.org/wiki/Principle_of_least_privilege).
>
> There should (could) be a way to add new behaviour to old data without
> touching the old data (class). Traits won't work in this use-case,
> since they assume the same internal structure for all trait-using
> classes. Imagine the `stringable` interface and a `toString` trait. A
> __toString() method needs knowledge about the internal structure of a
> class Foo. Yet if we want to keep adding behaviour to Foo, we'll end
> up with either exposing too much of Foo, or expanding the class file
> indefinitely. Please note that composition is not a proper solution,
> since it requires exposure of Foo; composition leads to lack of proper
> encapsulation, or representation exposure.
>
> In Haskell it's possible to split instance implementation of
> type-classes into separate files. In Rust you can have a struct with
> private fields and put impl of behaviour in different files (but same
> crate).
>
> A similar feature in PHP could look like (using new keyword `expand`
> but could be anything, or even `extend` in new context):
>
> ```
> // File FooStringable.php
> expand Foo implements stringable {
>   public function __toString() {
> // Full access to Foo's all private fields here.
> // Assumes you can autoload Foo.
> // Assumes usage of $foo->__toString(); will be configured with
> autoload to dynamically find the correct behaviour of Foo.
>   }
> }
> ```
>
> If you'd use composition instead, you'd maybe have a formatter class
> with a method `$formatter->toString(stringable $foo)`. This has the
> problem I mentioned with exposing too much of $foo; it breaks
> encapsulation. It has the benefit of being able to provide multiple
> toString methods with different formats, but would have to assume
> similar structure of the objects passed to it (defined with an
> interface), which is not always possible or desirable.
>
> The other way is inheritance, which doesn't scale over multiple
> behaviours. `FooWithStringable extends Foo`? No.
>
> Was I clear here? Do you understand the issues that this design
> pattern is trying to solve? Its purpose is to solve "keep adding new
> feature to old data" in a clean and proper way, while keeping
> information encapsulation.
>

Do I understand you correctly, it would be somewhat like "opening" up a
class and making changes to it in another file?

Certainly a powerful concept, but I would be very interested in the details
how that would interact with autoloading. If I have a class Foo loaded, and
its "extension" FooString with toString method not, then it would lead to
the "toString" code missing.

>
> Enjoy the weekend!
> Olle
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Support PAM in PHP8

[Benjamin Eberlei]

On Fri, Aug 21, 2020 at 4:19 PM Volker Theile <
volker.the...@openmediavault.org> wrote:

> Hi all,
>
> i've opened the tracker issue https://bugs.php.net/bug.php?id=80004
> which requests Linux PAM (pluggable authentication modules) support in
> PHP8. IMO PAM is an essential feature that is required by professional
> applications. Sadly the PECL extension https://pecl.php.net/package/PAM
> is not maintained anymore and can't be used in PHP7 without patching it.
> I fear with PHP8 this will not be possible anymore.
>
> Because of that i want to bring up this topic and start a discussion if
> it is possible to integrate PAM support in the origin Git source tree,
> so package maintainer (e.g. Debian, Ubuntu, ...) can activate it simply
> via build flag and ship this extension through their packages. By
> integrating it into the origin source tree there is no need for a PECL
> extension anymore, the benefit of this will be that the code is always
> up-to-date and can be build out of the origin source.
>

The code needs to be maintained by someone to be up to date, putting it
into php-src will not magically solve that issue.

I don't think PAM has a chance of ever getting into php-src, even if the
PECL module is well maintained. It is just too specific, and the exact
reason that PECL exists. Do you see yourself taking over the maintainership
by any chance? apply the patches for PHP 7 compatibility and work on PHP 8?

>
> Regards
> Volker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Attribute Syntax Revote

[Benjamin Eberlei]

On Fri, Aug 21, 2020 at 3:36 PM Paul M. Jones  wrote:

> Hi all,
>
> On Aug 21, 2020, at 08:23, Benjamin Eberlei  wrote:
>
> It was stopped and reset last week, because it was started too early.
>
>
> Ah, I see -- I received the message I quoted *after* I placed a vote
> yesterday, so I thought it had been reset *yet again*. Glad that I was
> wrong ...
>

Ah yes, we thought that maybe some people did not see that we did the
reset, and saw the new [VOTE] thread and assumed they have already voted.
So we wrote to everyone to make sure that they see it was reset. We could
have mentioned more precise dates to clarify, but it should work out either
way.

>
>
> I remember that you were one of the people to request this :-)
>
>
> ... but to be clear, I noted that the proper thing to do was to restart
> the two-week discussion period, thus resetting the time at which the vote
> could be held. Obviously that was not done.
>
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>

Re: [PHP-DEV] Attribute Syntax Revote

[Benjamin Eberlei]

It was stopped and reset last week, because it was started too early. I
remember that you were one of the people to request this :-) See my
explanation here https://externals.io/message/111416#111553

On Fri, Aug 21, 2020 at 3:12 PM Paul M. Jones  wrote:

> Hi everyone --
>
> 1. Did anyone else here get this message (below) from Derick yesterday?
>
> 2. Maybe I missed something -- why was the vote reset?
>
> >
> > From: Derick Rethans 
> > Subject: Attribute Syntax Revote
> > Date: August 20, 2020 at 10:36:36 CDT
> > To: Derick Rethans 
> >
> > Hi!
> >
> > I'm reaching out because you had voted in the "New Attribute Syntax
> > Choice" poll. This poll has been *reset* and your original vote has been
> > discarded.
> >
> > The vote has now been restarted, so please indicate your choice again,
> > if you have not done so yet:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> >
> > Please note that there are now 6 options.
> >
> > cheers,
> > Derick
> >
>
> --
> Paul M. Jones
> pmjo...@pmjones.io
> http://paul-m-jones.com
>
> Modernizing Legacy Applications in PHP
> https://leanpub.com/mlaphp
>
> Solving the N+1 Problem in PHP
> https://leanpub.com/sn1php
>
>
>
>

Re: [PHP-DEV] Re: [VOTE] Shorter Attributes Syntax Change

[Benjamin Eberlei]

On Thu, Aug 20, 2020 at 9:13 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Wed, 19 Aug 2020 21:11:29 +,
> Theodore Brown  a écrit :
> > In case anyone wants to view the in-progress STV vote results, I took
> > the same script I made for the Shorter Attribute Syntax RFC and made
> > it possible to run online here:
> >
> >
> https://stv-results.theodorejb.me/php/?rfc=shorter_attribute_syntax_change
> >
> > Note that at present it only processes the STV vote and ignores the
> > primary 2/3 poll result, so keep that in mind.
>
> Thank you, I was searching for something like this!
>
> Is there any chance we can see the code? (mostly out of curiosity)
>
> Also, is it supposed to be updated at page load or at some time interval?
> I see 15 votes on the RFC page for #[] and 14 on your page.
>

With 30 voters its likely one voted for the same thing twice accidentally
and the vote is disqualified. Afaik Derick's script outputs that so the
voter can be notified about their mistake.

>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] Re: [VOTE] Shorter Attributes Syntax Change

[Benjamin Eberlei]

I wanted to clarify that this is the **restarted* vote on Shorter Attribute
Syntax Change, that means all votes cast between August 11th and 15th have
been reset.

On Wed, Aug 19, 2020 at 12:50 PM Benjamin Eberlei 
wrote:

> Hello everyone,
>
> We have started the vote on "Shorter Attributes Syntax Change" RFC to
> decide one last time on what syntax to choose for the Attributes feature.
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
> The first vote is a vote to say that you have an opinion about attribute
> syntax.
>
> The second vote is an STV vote.
>
> In STV you SHOULD rank *all* choices, but don't pick the same one more
> than once, as that will invalidate your vote.
>
> Please see the introduction for multiple arguments on why we should revote.
>
> In addition to the table and Syntax Side by Side giving an overview on the
> differences of each syntax, there is also an extensive discussion of the
> various arguments below.
>
> Thank you to everyone participating in the discussion.
>
> The vote ends September 2nd, 12:00 UTC.
>
> cheers,
> Derick and Benjamin
>

[PHP-DEV] [VOTE] Shorter Attributes Syntax Change

[Benjamin Eberlei]

Hello everyone,

We have started the vote on "Shorter Attributes Syntax Change" RFC to
decide one last time on what syntax to choose for the Attributes feature.

https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting

The first vote is a vote to say that you have an opinion about attribute
syntax.

The second vote is an STV vote.

In STV you SHOULD rank *all* choices, but don't pick the same one more
than once, as that will invalidate your vote.

Please see the introduction for multiple arguments on why we should revote.

In addition to the table and Syntax Side by Side giving an overview on the
differences of each syntax, there is also an extensive discussion of the
various arguments below.

Thank you to everyone participating in the discussion.

The vote ends September 2nd, 12:00 UTC.

cheers,
Derick and Benjamin

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Wed, Aug 19, 2020 at 11:13 AM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:

> Please add discussion about merge conflicts. Any inline grouped
> attribute syntax needs a manual conflict resolution.
>
> With ungrouped syntax, I expect recommended CS to be one attribute per
> line.
>

This is discussed under grouping already. It is a coding style issue, so
it's not really relevant as you can use all the syntaxes in an ungrouped
mode if you are concerned about conflicts.


> If this should be the case also for grouped syntax, then it not +1
> character, but +2 new lines per every annotated element.
>
> Also, is 2/3 majority required by RFC rules satisfied by the "Are you
> okay with re-voting on the attribute syntax for PHP 8.0, again?"
> question?


> I think we should require 2/3 votes at least on the question if we
> should allow grouping or not and if accepted, use STV results on the
> prefered prefix symbols/syntax.
>

Yes, that was exactly the same type of vote for "shorter attribute syntax"
RFC.


>
> With kind regards / Mit freundlichen Grüßen / S přátelským pozdravem,
>
> Michael Voříšek
>
> On 19 Aug 2020 10:47, Benjamin Eberlei wrote:
>
> > On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei 
> > wrote:
> >
> > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:
> >
> > Hi,
> >
> > Out of Banjamin's suggestion[1 [1]], I've updated the Shorter Attribute
> > Syntax Change RFC to reflect that process:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Patches and comments welcome.
> >
> > FWIW, this has an excemption from the RM Sara as per [2 [2]]:
> >
> > * Shorter Attribute Syntax Change
> > - Joe/Derick - Please make sure this RFC moves along and reaches
> > conclusion by beta3, as discussed previously.
> > Heads up: This RFC is now going to vote tomorrow:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback as
> possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and ultimately
> not
> that important as downstream libraries just have to deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
>
> I don't think something major is missing now.
>
> One last change that I didn't see yesterday as it was on Github and not
> this list is the addition of another syntax proposal @{} with the same
> benefits as @[], a little more snowflake than compared to other
> languages,
> but without the BC Break.
>
> >> cheers,
> >> Derick
> >>
> >> [1] https://externals.io/message/111218#111261
> >> [2] https://externals.io/message/111286#111286
> >>
> >> --
> >> PHP 7.4 Release Manager
> >> Host of PHP Internals News: https://phpinternals.news
> >> Like Xdebug? Consider supporting me: https://xdebug.org/support
> >> https://derickrethans.nl | https://xdebug.org | https://dram.io
> >> twitter: @derickr and @xdebug
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
> Links:
> --
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Wed, Aug 19, 2020 at 11:01 AM Andreas Leathley 
wrote:

> On 19.08.20 10:47, Benjamin Eberlei wrote:
> > One last change that I didn't see yesterday as it was on Github and not
> > this list is the addition of another syntax proposal @{} with the same
> > benefits as @[], a little more snowflake than compared to other
> languages,
> > but without the BC Break.
>
> I mentioned the benefits of @{} in an email to this list on Monday, with
> the proposal to have both @@ and @{} as attribute syntax, so both camps
> could have their syntax (one with delimiters, one without) with minimal
> BC breaks, and leave the decision to the PHP developers/projects what
> they prefer in what circumstances, because there can be valid reasons to
> use both - I probably would use both. @{} could be good to define
> multiple attributes for classes/properties, @@ could be good for short
> attributes or ones very entrenched within the code, like function
> parameters. The @{} syntax could be amended in the future, so this would
> also be "future-proof".
>
> But I guess the division about syntax is too big at this point to
> consider an approach where we just offer both types of syntax. From a
> PHP developer viewpoint, it would be preferable though.
>

The "problem" with having both @@ and @{} would be that we would need two
new tokens instead of one.

We have a bunch of proposals that would support both grouped and ungrouped
with the same syntax, so a solution that ends up ending two new tokens and
syntaxes would be less preferable.

With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei 
wrote:

>
>
> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:
>
>> Hi,
>>
>> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
>> Syntax Change RFC to reflect that process:
>>
>> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>>
>> Patches and comments welcome.
>>
>> FWIW, this has an excemption from the RM Sara as per [2]:
>>
>> > * Shorter Attribute Syntax Change
>> >- Joe/Derick - Please make sure this RFC moves along and reaches
>> >  conclusion by beta3, as discussed previously.
>>
>> Heads up: This RFC is now going to vote tomorrow:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> I have updated the RFC one last time with as much of the feedback as
> possible:
>
> - a section about comparing to complexity of type definitions
> - removal of the machine reading section as too narrow and ultimately not
> that important as downstream libraries just have to deal with any of it
> - some more nuances in forward compatibility pro/cons section of #[]
> - smaller corrections and improvements.
>
> I don't think something major is missing now.
>

One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.

>
>
>>
>> cheers,
>> Derick
>>
>> [1] https://externals.io/message/111218#111261
>> [2] https://externals.io/message/111286#111286
>>
>> --
>> PHP 7.4 Release Manager
>> Host of PHP Internals News: https://phpinternals.news
>> Like Xdebug? Consider supporting me: https://xdebug.org/support
>> https://derickrethans.nl | https://xdebug.org | https://dram.io
>> twitter: @derickr and @xdebug
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Wed, Aug 19, 2020 at 12:03 AM Theodore Brown 
wrote:

> On Tue, Aug 18, 2020 at 1:00 PM Benjamin Eberlei 
> wrote:
>
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > I have updated the RFC one last time with as much of the feedback
> > as possible:
> >
> > - a section about comparing to complexity of type definitions
> > - removal of the machine reading section as too narrow and
> >   ultimately not that important as downstream libraries just have to
> >   deal with any of it
> > - some more nuances in forward compatibility pro/cons section of #[]
> > - smaller corrections and improvements.
> >
> > I don't think something major is missing now.
>
> Hi Benjamin,
>
> Thanks for the updates. I just have a few more thoughts on aspects
> that haven't been mentioned before:
>
> 1. The **Attributes are not like Modifiers** section makes an
>argument that having an end delimiter "groups docblock comment and
>attributes into two similarly shaped syntax blocks that prefix the
>declaration increasing familiarity."
>
> In my own (admittedly subjective) opinion, an end delimiter on
> attributes actually increases confusion when there is also a
> docblock. To reuse the example from the RFC:
>
> /**
>  * A comment describing things.
>  *
>  * @psalm-suppress SomeRule
>  */
> #[
> ORM\Entity(),
> ORM\Table("baz")
> ]
> final class Something {
> }
>
> Because the attribute group has its own start and end delimiters, it
> almost looks like the doc comment applies to the attribute block
> rather than the class.
>
> With the `@@` or `@:` syntax, it seems clearer that attributes are
> part of the class/function/property declaration, rather than their
> own standalone construct which docblocks can be applied to:
>
> /**
>  * A comment describing things.
>  *
>  * @psalm-suppress SomeRule
>  */
> @@ORM\Entity
> @@ORM\Table("baz")
> final class Something {
> }
>
>
> Given that the only complex part of an attribute is the optional
> argument list, which already has its own start/end delimiters, I
> ultimately don't find the "complexity" argument very compelling for
> needing an additional attribute end delimiter besides.
>

>
> 2. In the **Discussion on grep'ability** section, the RFC says
>"Enforcement of same line is also not the case for other
>declarations that benefit from grep'ability such as classes,
>functions, constants and so on in PHP already, so this is not
>consistent within the language."
>
> This seems to be outdated information, based on Martin's original
> patch before the "Treat namespaced names as single token" RFC was
> accepted. In the current `@@` implementation, there is no single-line
> enforcement, consistent with other parts of the language.
>

Right, i didn't realize this restriction was lifted and updated this
section.

This doesn't change the argument though that when you need coding styles to
enforce a particular style that grepability works, then you can find a
coding standard with all syntaxes that has good grepability, i.e. by not
using grouping.

>
> Not having whitespace between the attribute token and name would be
> enforced by coding style conventions, just as is the case with
> function/class/constant definitions.
>
> Note that there is some precedent in PHP for choosing syntax that
> ensures easier searching (for example, the decision to place return
> type declarations after the parameter list rather than before the
> function name).
>
> Grep'ability isn't a big deal when finding usages in an IDE, but
> sometimes there is a need to search code on a server or other source
> without an IDE, in which case easy grep'ability can be very helpful.
>
> Sincerely,
> Theodore

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:

> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an excemption from the RM Sara as per [2]:
>
> > * Shorter Attribute Syntax Change
> >- Joe/Derick - Please make sure this RFC moves along and reaches
> >  conclusion by beta3, as discussed previously.
>
> Heads up: This RFC is now going to vote tomorrow:

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

I have updated the RFC one last time with as much of the feedback as
possible:

- a section about comparing to complexity of type definitions
- removal of the machine reading section as too narrow and ultimately not
that important as downstream libraries just have to deal with any of it
- some more nuances in forward compatibility pro/cons section of #[]
- smaller corrections and improvements.

I don't think something major is missing now.


>
> cheers,
> Derick
>
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 8:49 AM Aleksander Machniak  wrote:

> On 18.08.2020 00:35, Mike Schinkel wrote:
> > 1. Postpone inclusion of attributes until PHP 8.1
>
> +1
>
> I wonder why my suggestion (somewhere in this thread) didn't get any
> attention. Is it because the ship had sailed or it's a terrible idea?
>

A suggestion requires a patch, otherwise it's just theoretical.

One problem I see with your suggestion is the conflict in a code like this:


> declare(
> SomeAttr,
> AnotherAttr("Hello world")
> )
> function someFunc() {
> }
>
> It's almost identical to #[] or @[], but it looks like PHP and has no BC
> breaks. To me it also sounds good - "declare attribute(s) [for] something".
>
> ps. sorry Mike for a duplicate, I pressed the wrong button.
>
> --
> Aleksander Machniak
> Kolab Groupware Developer[https://kolab.org]
> Roundcube Webmail Developer  [https://roundcube.net]
> 
> PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Tue, Aug 18, 2020 at 12:36 AM Mike Schinkel  wrote:

> I have been following all the lengthy discussions on this topic hoping the
> list would come to consensus. And I had been hoping someone would call the
> following question but since no one else has here goes.
>
> The concept of adding attributes to PHP seemed to sail to acceptance but,
> if you count the original RFC there have been three (3) different RFCs each
> with the goal of setting or changing the decided syntax alone.
>
> For every syntax proposed there seems to be a contingent of people who are
> deeply troubled by it. Given that once a syntax lands in an official
> release of PHP there are not take backs, moving forward with any syntax
> where people are so divided seems like a really bad idea.
>
> If we care about future developers being happy enough with the decisions
> made about PHP to continue choosing PHP that I would think it would be
> incumbent upon us to find a syntax with a greater level of buy-in.
>
> Should we not:
>
> 1. Postpone inclusion of attributes until PHP 8.1 to ensure that we get a
> syntax that is reasonable acceptable to large segment of stakeholders?
>

All the technically complex decisions are done, tested and decided. The
syntax question is still open, but not critical from a technical
implementation POV. All patches regardless of syntax are extremely similar,
just replacing symbols. The non-technical implications and future related
questions are what is up for decision. The arguments for or against these
categories are by now driving in circles. Postponing to 8.1 does therefore
not bring additional value. A decision has to be made and we have enough
time for that.

>
> 2. Optionally have an RFC to ask people to vote on disputed principles,
> such as "Are ending delimiters important and thus are they required for any
> selected syntax?"
>

By voting for a syntax, these questions are answered implicitly.

>
> 3. Then open up the floor for more syntax proposals (that address all the
> accepted principles in #2) in hopes to find something generally acceptable
> to a larger segment of stakeholders with a goal of completing by 8.1?
>
> -Mike
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 5:

14 PM Theodore Brown  wrote:

> On Mon, Aug 17, 2020 at 8:07 AM Theodore Brown 
> wrote:
>
> > On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei 
> wrote:
> > > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown 
> wrote:
> > > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > > >
> > > > The RFC shows an example of a potential "simpler" attribute using a
> > > > string instead of a class name. I honestly have no idea what this is
> > > > supposed to do or what benefit it would have over normal attributes.
> > > >
> > > > The concept of attributes being a class name with optional arguments
> > > > has been proven over many years by its use in docblock annotations,
> > > > and if there was some deficiency in what this syntax allows it seems
> > > > like we would have discovered it by now.
> > >
> > > I agree on just the string, but a closure would make 100% sense for
> > > a decorating feature. Javascript and Python "Attributes" work as
> > > decorators, i.e. they get called around the decorated function.
> > >
> > > It is not a completely unrealistic feature to think off:
> > >
> > > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > > function foo($message) {}
> >
> > As I understand it JavaScript decorators do not use anonymous
> > functions for decorators like this, though. Instead you would make a
> > named function and apply it with `@myFunc()` before the decorated
> > function or class.
> >
> > Presumably we could accomplish the same thing in PHP with e.g. an
> > `__invoke` method in the attribute class, without complicating the
> > attribute syntax itself.
>
> One other thought on this. I agree that decorators are not a
> completely unrealistic future feature. However, it must be noted that
> both JavaScript and Python use the `@Attr` syntax for decorators, and
> the lack of an end delimiter in no way precludes this usage.
>

Yes they support decorators with @, but they don't support metadata.

With this syntax its either or, because from @Attr only you cannot decide
if its a decorator or a metadata attribute.

It would not work by detecting __invoke on the Attribute, because the whole
architecture of Attributes is based on deferring autoloading until
Reflection*::getAttributes().
But when you use decorators, you would need to know this at runtime, so the
zend_attribute datastructure would need to know its not an metadata
attribute,
but a decorator.


> The whole point of a decorator is to offer syntax sugar for a common
> reusable pattern (pass a function/class to another function which can
> add additional information or behavior to it). It's not clear how an
> anonymous closure would be useful for this, since it would not allow
> reusability, which defeats the purpose.
>
> So the argument that an end delimiter has "potential future benefits"
> still lacks any realistic examples, and is countered by years of
> proven usage of the `@Attr` syntax in docblocks and other languages.
>
> Sincerely,
> Theodore

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 2:29 PM Benjamin Eberlei 
wrote:

>
>
> On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer  wrote:
>
>> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei 
>> wrote:
>>
>>> We have updated the RFC at
>>> https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we
>>> think
>>> covers all the discussion and arguments made in this and the previous
>>> mailing list threads.
>>>
>>
>> Thank you for putting in the work it took to revise the RFC. It's good. I
>> now understand what the delimiters achieve.
>>
>> While I don't agree with the first point in "Forcing @@ Attributes to end
>> with parenthesis does not solve issues" (in this new syntax I'd ban
>> whitespace) I appreciate the point you are making, and it is sensible for
>> consistency.
>>
>> I feel grep'ability has been played down, as unless
>> @@
>> MyProject\FooAttr
>>
>> is allowed (which isn't shown in the codeblock), then it's easier to grep
>> for @@.+?Foo and know you have a chance of an accurate match (assuming
>> renaming is not used) than it is with the delimiter syntax.
>>
>
> no space is allowed between @@ and name, they have to be in the same line.
> The whitespace between name and argument_list is not currently banned, the
> comparison is to the status quo (since that is not expected to change).
>

Correction, I was made aware that this is not true, a space betwen @@ and
attribute name is allowed at the moment:

@@
   MyProject\FooAttr
function foo() {}

is allowed.

>
> Still I think the grepability has to rest on no assumptions, because
> otherwise you could argue the same for @[] being used non-grouped on one
> line and would have to conclude that this is also grepable.
>
>>
>> Sorry to everyone for causing this hazzle.
>>>
>>
>> These things happen. Thank you for taking on-board the feedback and
>> working on the RFC.
>>
>> Peter
>>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 10:02 AM Peter Bowyer  wrote:

> On Sun, 16 Aug 2020 at 10:29, Benjamin Eberlei 
> wrote:
>
>> We have updated the RFC at
>> https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we
>> think
>> covers all the discussion and arguments made in this and the previous
>> mailing list threads.
>>
>
> Thank you for putting in the work it took to revise the RFC. It's good. I
> now understand what the delimiters achieve.
>
> While I don't agree with the first point in "Forcing @@ Attributes to end
> with parenthesis does not solve issues" (in this new syntax I'd ban
> whitespace) I appreciate the point you are making, and it is sensible for
> consistency.
>
> I feel grep'ability has been played down, as unless
> @@
> MyProject\FooAttr
>
> is allowed (which isn't shown in the codeblock), then it's easier to grep
> for @@.+?Foo and know you have a chance of an accurate match (assuming
> renaming is not used) than it is with the delimiter syntax.
>

no space is allowed between @@ and name, they have to be in the same line.
The whitespace between name and argument_list is not currently banned, the
comparison is to the status quo (since that is not expected to change).

Still I think the grepability has to rest on no assumptions, because
otherwise you could argue the same for @[] being used non-grouped on one
line and would have to conclude that this is also grepable.

>
> Sorry to everyone for causing this hazzle.
>>
>
> These things happen. Thank you for taking on-board the feedback and
> working on the RFC.
>
> Peter
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Sun, Aug 16, 2020 at 4:47 PM tyson andre 
wrote:

> Hi Benjamin,
>
> > We are looking for further feedback from the community.
>
> Thanks, the updated RFC looks much better.
> Some more feedback on why the edge cases are a concern to me,
> and why the lack of an ending delimiter is similar to parsing problems
> already faced.
>
> I'd agree that restarting a two-week discussion period seems excessive,
> and a shorter one is fine with me.
>

Thank you for the feedback, the section on #[] forward compatibility is
something I want to improve a bit more today, your feedback helps a lot.

>
> 
>
> The references section should probably also link to the other 2 RFC
> discussion threads
> https://externals.io/message/111416 and the RFC discussion thread
> https://externals.io/message/111218
>
> 
>
> Developers who are new to PHP (e.g. learning by example) or those who
> spend most of their time programming in other languages such as Rust or
> Java or Golang
> might forget/not know that `#` is a supported line comment syntax, or that
> attributes were introduced in 8.0 (not an earlier release).
> They might see that code using these edge cases passes syntax checks in
> PHP 7.4 and 8.0, and assume it'd work the same way in both versions,
> leading to published code incorrectly marked as compatible with PHP 7.4.
>
> - PHP doesn't warn about calling a user-defined function too many
> parameters, making this harder to detect.
>
> 
>
> The `#[]` syntax makes it possible and convenient to use attributes syntax,
> but causes various problems for end users of code using attributes syntax.
> I'd expect the drawbacks of bugs caused by edge cases such
> as those in
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#discussion_of_forwards_compatibility_procons
> to outweigh the benefits of being able to release attributes immediately.
>
> Putting attributes on the same line as parameters or closures or anonymous
> classes seems natural to do to me,
> and I'd expect releases would do it eventually, whether it be immediately
> in 8.0, years from now, etc.
>
> Suppose that package `A/A` supports PHP `7.4|^8.0`.
> It depends on a package `B/B` 2.0 which supports PHP 7.4.
> `B/B` depends on `C/C` `^4.0|^5.0`, where C/C 4.x supports PHP 7
> and C/C 5.0 drops support for PHP 7.
> C/C 5.x uses attribute syntax on the same line as other code,
> including several edge cases with one-line attributes that parse
> differently in php 7.0.
>
> ```
> public function doDbMaintenance(
> #[MyUnused] bool $log = false,  // unused in db backend
> bool $doPotentiallyDestructiveUpdate = false,
> mixed $extraFlags = null,
> ) {...}
>
> // B/B calls doDbMaintenance($log = true)
> ```
>
> Then suppose that a maintainer or third-party packager (e.g. for a Linux
> distro) of `A/A`
> runs composer install with PHP 8.0 before building a package such as a
> phar, rpm, or tarball
> (or `vendor/` checked into git) from `A/A` 1.0.
> They would pull in B/B 2.0 and C/C 5.0, creating a release of A/A that was
> buggy
> but did not emit any parse, compilation, or runtime warnings if end users
> ran that release with php 7.4.
>
> Then the maintainers of `A/A` and `C/C` 5.0 would get bug reports for PHP
> 7.4 for mysterious behaviors with no warnings,
> which would be hard to reproduce and debug, despite all involved packages
> correctly specifying their dependencies.
> End users would also be inconvenienced by bugs that had no obvious
> indication or subtler symptoms that may take a long time to get reported.
>
> This could be worked around by
>
> 1. Setting `{"config": {"platform": {"php": "7.4.9"}}}` in composer.json
> of A/A,
>or by documenting that `composer install` should always be run with PHP
> 7.4,
>but I wouldn't expect new composer users to be aware of the ability to
> do that
>until they run into issues, and that doesn't help if A/A is a
> dependency of another package.
>
> 2. C/C 5.0 could exit() when bootstrapping when it's run in php 7,
>but that seems excessive and not currently done by libraries in my
> experience.
>
> 
>
> If a developer needs to backport code or patches for php 8.0+ to php 7.4
> or older
> (e.g. to support legacy applications or OSes that make updating php
> impractical),
> the lack of a syntax error would make this backporting error prone
> if the developer didn't remember this incompatibility
> or learn about tools created to catch issues.
> (or didn't know about *up-to-date, bug-free* tools to downgrade php syntax)
>
> 
>
> For
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#machine_scanning_for_end_of_attribute_declaration
> I'd agree that the lack of an ending delimiter makes token-based
> extraction more complicated but still practical,
> but it is a complexity that projects such as phpcs **would already face in
> similar syntaxes.**
> The problems with whitespace and comments and doc comments between tokens
> can be fixed by filtering

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 10:59 AM Alexandru Pătrănescu 
wrote:

> On Sun, Aug 16, 2020 at 12:36 PM Benjamin Eberlei 
> wrote:
> >
> > We have updated the RFC with all (hopefully) of the feedback from this
> > discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most notable changes are:
> > - A new section with several subsections on the benefits of a closing
> > delimiter / enclosing syntax.
> > - A section on grouping pro/cons
> > - Inclusion of @: as per Theodores request
> >
> > We are looking for further feedback from the community.
>
> Thanks for the work. Looks good.
> An idea.
>
> Would the syntax @ be able to obtain a "No" on the "Breaks BC of
> valid PHP 7 code" section while still being more or less the same as
> #[Attr] or @[Attr] considering other features?
> BTW, I'm thinking that it's good to have a "No" there.
>
> Sorry if proposing another syntax is making this an even more complex
> problem.
>

It is ok to propose another syntax, at this point in time we are working
around the @ and [] symbols, because of their familiarity with other
languages attribute syntax.

There is probably 100 potential syntaxes that we could use, @<> is a bit
hard on the eyes as is <<>>, so i wouldn't call it a game changer in
contrast to what we have already, so I would rather not include it.

>
> Regards,
> Alex
>
> > On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:
> >
> > > Hi,
> > >
> > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > > Syntax Change RFC to reflect that process:
> > >
> > > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> > >
> > > Patches and comments welcome.
> > >
> > > FWIW, this has an excemption from the RM Sara as per [2]:
> > >
> > > > * Shorter Attribute Syntax Change
> > > >- Joe/Derick - Please make sure this RFC moves along and reaches
> > > >  conclusion by beta3, as discussed previously.
> > >
> > >
> > > cheers,
> > > Derick
> > >
> > > [1] https://externals.io/message/111218#111261
> > > [2] https://externals.io/message/111286#111286
> > >
> > > --
> > > PHP 7.4 Release Manager
> > > Host of PHP Internals News: https://phpinternals.news
> > > Like Xdebug? Consider supporting me: https://xdebug.org/support
> > > https://derickrethans.nl | https://xdebug.org | https://dram.io
> > > twitter: @derickr and @xdebug
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: https://www.php.net/unsub.php
> > >
> > >
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown 
wrote:

> On Sun, Aug 16, 2020 at 4:36 AM Benjamin Eberlei 
> wrote:
>
> > We have updated the RFC with all (hopefully) of the feedback from
> > this discussion:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Most notable changes are:
> > - A new section with several subsections on the benefits of a closing
> > delimiter / enclosing syntax.
> > - A section on grouping pro/cons
> > - Inclusion of @: as per Theodores request
> >
> > We are looking for further feedback from the community.
>
> Hi Benjamin and Derick,
>
> Thank you for taking the time to further flesh out the RFC and
> include the `@:` syntax option. Overall it is a lot better now.
> However, I still have some concerns with several claims in the RFC
> that are inaccurate or incomplete, particularly in the "Discussion
> on Ending Delimiter / Enclosing Delimiters" section. [1]
>
> The RFC intro says "we should strongly favor a syntax with closing
> delimiter to keep consistency with other parts of the language". It
> is then argued that "Many complex syntax constructs in PHP have an
> ending delimiter", and therefore attributes should have one as well.
>
> However, ending delimiters in PHP have little to do with how "complex"
> a syntax construct is (which is a rather loose definition, anyway).
> As I've pointed out before, standalone statements and declarations
> generally require an end symbol, but modifiers before a declaration
> do not. Attributes fall into the latter category, and therefore the
> lack of an end delimiter is consistent.
>

A docblock is also a "modifier" under your declaration and it has an ending
symbol.

The RFC gives a  definition of the complexity as just a token vs a set of
name, arugment_list and constant expression parser rules. It shows
an example porting an ORM\JoinTable Attribute, which has arguments, named
parameter usage, complex definitions of default values (Strings, arrays).

This piece of code probably touches 10-20 parser rules.

Most modifiers don't even have a parser rule, as they only match their
token.

>
> The RFC responds to this counterargument with a series of four
> claims, none of which is fully accurate in describing declaration
> modifiers:
>
> 1. Even if we only consider keyword declaration modifiers, the claim
> that "these modifier keywords all have only exactly one token that
> can immediately follow them, T_WHITESPACE" is not correct. Just as
> with attributes, modifier keywords can also be followed by a comment
> token (#, //, or /**/):
>
> @@Attribute// some comment
> final// some comment
> class Foo {...}
>
> Strangely, the RFC only lists keywords like public and final as
> declaration modifiers, and neglects to mention that type declarations
> are also in this category (which I have pointed out in all my
> previous responses to this argument).
>

> Type declarations can be not only followed by whitespace and comment
> tokens, but also a `T_VARIABLE` token:
>
> function foo(Type$bar) {}
>

> 2. The RFC goes on to claim that "[declaration modifiers] are all
> non-complex and are only made up of a handful ascii letters". Again,
> this fails to consider type declarations, which can contain the same
> non-ascii characters that attribute names can.
>

Types are missing indeed, and they are more complex than a simple token,
but less complex than attribute declarations.

I guess the difference is that union types are new, and type definitions
used to be simple. Attributes however are *new*
and already complex, so we still have the option of always enclosing them.


> 3. Next, the RFC says "these keywords are always on a single line".
> But union type declarations can be spread across multiple lines,
> and still don't have an end delimiter:
>
> function foo(
> \My\FullyQualified\ClassName
> |string $param
> ) {...}
>
> 4. Finally, the RFC says that "visibility keywords are only boolean
> or bitflags in Reflection, but Attributes are a full fledged
> `ReflectionAttribute` representing their own distinct language concept."
> You can probably guess where I'm going with this... Type declarations
> are likewise a fully fledged `ReflectionType` representing their own
> distinct language concept.
>
> So the RFC's argument that attributes need to have a distinct ending
> symbol for consistency is not convincing. The lack of an ending
> delimiter is fully consistent with other declaration modifiers,
> whether simple or complex.
>
> ## Benefits for IDEs and 

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

We have updated the RFC with all (hopefully) of the feedback from this
discussion:

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

Most notable changes are:
- A new section with several subsections on the benefits of a closing
delimiter / enclosing syntax.
- A section on grouping pro/cons
- Inclusion of @: as per Theodores request

We are looking for further feedback from the community.

On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:

> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an excemption from the RM Sara as per [2]:
>
> > * Shorter Attribute Syntax Change
> >- Joe/Derick - Please make sure this RFC moves along and reaches
> >  conclusion by beta3, as discussed previously.
>
>
> cheers,
> Derick
>
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni  wrote:

> On Sun, Aug 16, 2020 at 1:00 AM Benjamin Eberlei 
> wrote:
> >>
> >> The RFC says that
> >> > The main concern is that @@ has no ending symbol and it's
> inconsistent with the language
> >> > that it would be the only declaration or statement in the whole
> language that has no ending termination symbol.
> >> However, it's clear that attributes are neither a declaration nor a
> >> statement, but metadata about the thing that follows them (unless it's
> >> more attributes or comments).
> >> The ultimate proof of this is that a semicolon after an attribute is
> illegal.
> >
> > I would like to chime in here since this argument is made over and over
> again, even though it overlooks an important point. when we say that
> attributes are just metadata, then let's compare them to docblocks with
> *are* always enclosed in /** and */ instead of visibility keywords.
> >
> > This comparison is fair, because doc comments are often multi line and
> attributes are as well. When doc comments are single line, they are also
> enclosed.
> >
> > Whereas a comparison with visibility modifiers that are *just* tokens
> that *always* are followed by a T_WHITESPACE is apples vs oranges, because
> @@ attributes can be followed by a large set of different things:
> >
> > @@Foo @@Bar // ends due to T_WHITESPACE with " "
> >  @@Foo // ends due to T_WHITESPACE with "\n"
> >  @@Foo() // ends due to )
> >  @@Foo () // ends with ), the T_WHITESPACE between class and arguments
> is valid
> >  @@Foo@@Bar // ends due to new T_ATTRIBUTE
> >  @@Foo()@@Bar // ends due to )
> >  @@Foo
> >  ("bar") // ends here in the second line at )
> >  function a_function() {
> >  }
> >
>
> Hi Benjamin,
>
> I'm sorry, but I don't understand your argument.
> It's true that annotations used to be enclosed in a docblock, but that
> is not an argument for saying that attributes NEEDS to be enclosed in
> a block too.
> It's also true that attributes can be followed by many different
> things, but still it doesn't follow that block enclosing is NECESSARY.
> What I'm saying is that there is still no good argument for why
> attribute block syntax is better than non-block syntax.
> The only argument that was presented in the original RFC was not
> convincing, and I pointed out why.
>

Nobody says it's ultimately **necessarry** as @@ can work.

The argument does not have to be convincing to everyone as we are not
making decisions by 100% majority.

We are bringing forward a set of arguments why we think end delimiters and
enclosing syntax is better and keeps more options open for the future.


> I'm also not saying that non-block syntax is better.
> Hence, it seems it's just a matter of taste, so far - unless we get to
> see some convincing arguments in the rewritten RFC.
>
> Thanks,
> Jakob
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

Following the valid criticisms of us starting the vote too early, we have
closed the vote for this RFC for now.

We look to restart the vote middle next week, so that we can close this
before the Beta 3 release on September 3rd.

We have updated the RFC at
https://wiki.php.net/rfc/shorter_attribute_syntax_change with what we think
covers all the discussion and arguments made in this and the previous
mailing list threads.

Sorry to everyone for causing this hazzle.

On Mon, Aug 10, 2020 at 10:41 AM Derick Rethans  wrote:

> Hi,
>
> I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
> The first vote is a vote to say that you have an opinion about attribute
> syntax. Make sure to read up on the discussion on the mailinglist if you
> haven't done so yet.
>
> The second vote is an STV vote.
>
> In STV you SHOULD rank *all* choices, but don't pick the same one more
> than once, as that will invalidate your vote.
>
> Please have a objective look at the table
> (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> don't just go by asthetics.
>
> The vote ends August 23, 24:00 UTC.
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Sat, Aug 15, 2020 at 11:47 PM Jakob Givoni  wrote:

> This will probably be my only contribution to this thread so I'll keep
> it simple:
>
> Am I in favor of a revote? Yes
> Can I vote myself? No
> Do I think a revote will change anything? No
> Have there been any good arguments for why attributes need an ending
> delimiter? No
>
> The RFC says that
> > The main concern is that @@ has no ending symbol and it's inconsistent
> with the language
> > that it would be the only declaration or statement in the whole language
> that has no ending termination symbol.
> However, it's clear that attributes are neither a declaration nor a
> statement, but metadata about the thing that follows them (unless it's
> more attributes or comments).
> The ultimate proof of this is that a semicolon after an attribute is
> illegal.
>

I would like to chime in here since this argument is made over and over
again, even though it overlooks an important point. when we say that
attributes are just metadata, then let's compare them to docblocks with
*are* always enclosed in /** and */ instead of visibility keywords.

This comparison is fair, because doc comments are often multi line and
attributes are as well. When doc comments are single line, they are also
enclosed.

Whereas a comparison with visibility modifiers that are *just* tokens that
*always* are followed by a T_WHITESPACE is apples vs oranges, because @@
attributes can be followed by a large set of different things:

@@Foo @@Bar // ends due to T_WHITESPACE with " "
 @@Foo // ends due to T_WHITESPACE with "\n"
 @@Foo() // ends due to )
 @@Foo () // ends with ), the T_WHITESPACE between class and arguments is
valid
 @@Foo@@Bar // ends due to new T_ATTRIBUTE
 @@Foo()@@Bar // ends due to )
 @@Foo
 ("bar") // ends here in the second line at )
 function a_function() {
 }

We are working to integrate our arguments in favour of enclosing from that
Derick and I made in this and the previous thread into the RFC at the
moment, as the lack of them is a valid point of criticism.

Additionally, Derick and I are waiting for word from Sara and Gabriel at
the moment, but we suggested to close and reset the vote to wait until the
discussion period is over on Tuesday to accommodate the criticism of us
prematurely starting the vote (by accident, not intentionally). We will
take the time to update the RFC with all discussions from here and the
previous thread with arguments that have come up.


> Do I think attributes need an ending delimiter? No
> Would I prefer the @@ syntax? Yes
> Do I think @@ is ugly or difficult to type? No
> Is it just a subjective matter of personal taste? Yes
> Is this whole discussion almost entirely a subjective matter? Yes
> Is this email thread, the RFC, the voting and the discussion about
> extending it a farce? Yes
> Do I mind waiting until 8.1 to have attributes so that it can be done
> right? No
>
> Godspeed!
>
> Best, Jakob
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Fri, Aug 14, 2020 at 2:22 PM Theodore Brown 
wrote:

> On Thu, Aug 13, 2020 at 8:41 PM Levi Morrison 
> wrote:
>
> > > So, a week+ early, then? Surely that means the current vote null
> > > and void, to be reset entirely following a proper discussion period
> > > -- one without concurrent voting.
> >
> > I just want to make sure I understand: there are people who think we
> > haven't discussed the syntax for attributes yet?
> >
> > I assume this is a serious email, but I can't fathom why anyone cares.
> > We've discussed this subject soo much...
>
> Hi Levi and internals,
>
> There's certainly been a lot of discussion in general about
> attributes. However, there was not a reasonable opportunity to either
> discuss the specific arguments made in this RFC (e.g. the lack of a
> closing symbol being inconsistent), or submit patches for alternative
> syntaxes as Derick requested when he put up the RFC for discussion.
>
> I was very surprised that it went to vote less than six days after
> the discussion period started, right after the weekend no less,
> before I had a chance to submit my patch to include the @: syntax.
>
> I'm as weary of the discussion as anyone, and would like to see
> closure on this topic sooner rather than later. But if the voting
> rules aren't followed, how can the vote result be considered
> legitimate or binding?
>
> If the authors sincerely want the best outcome for the language (and
> I assume they do), what harm is there in deferring the vote until the
> discussion period has completed, and ensuring that the RFC addresses
> the arguments on both sides and contains all the relevant information
> for making a decision? Otherwise many contributors (myself included)
> just end up feeling unheard, unhappy, and unconfident that the right
> choice is being made.
>
> With this in mind, I'd like to respectfully make the following
> requests:
>
> 1. Defer voting until the two week discussion period is complete
> (Tuesday, August 18).
>

What do you mean by defer exactly? Stop voting or reset the vote? We were
thinking of extending the vote until September 1st.

>
> 2. Include a ranked voting option for @: and mention its pros and
> cons (it is equally concise as @@ with no BC break, but is somewhat
> harder to type). Patch link: https://github.com/theodorejb/php-src/pull/1
>

I am wondering where @: is suddenly coming from? It wasn't discussed in
both shorter attributes RFC and the discussion leading to this RFC.

There were a few other suggestions like $() or "using attribute", but none
of them was followed up upon. Nobody replied to my or Dericks message with
a specific interest in actually contributing another patch, including @:

>
> 3. Add a Backward Incompatible Changes section with examples of the
> code that the different syntax options would break.
>

Derick and I are working on this section to update the RFC later today. We
didn't consider this relevant, because the mitigation steps for all of them
is the same: a project wide search and replace to insert a space

Code search across open-source showed that the number of occurrences vary,
but are all extremely low.

In addition all BC breaks are clean cut and lead to a fatal error that is
unlikely to go undetected when upgrading to PHP 8 (specifically in contrast
to the number conversion RFCs BC breaks).


> 4. Add a Discussion section briefly summarizing the arguments that
> have come up on list. In particular this should include:
> a) Tyson's examples of #[] changing the meaning of code in
>unexpected ways between PHP 7 and 8 (e.g. a parameter
>attribute would remove the parameter when run on PHP 7).
>

This is also included in the update, but ultimately is covered by the
explanation for "Forward Compatibility" already mentioning that it does
only work with a subset (and hence does not work for some other subset).

b) An example of the downside of grouping, where it causes
>unnecessary diff noise when adding or removing a second
>attribute on its own line.
>

This is a problem for coding styles to solve and is nothing the RFC should
be concerned with. Grouped syntax specifically includes support trailing
commas. Diff noise is something all declarations
with optional elements can cause, even use of @@ in one line can be
"forced" from single to multi lines creating diff noise under reasonable
Coding Standard assumptions.
As such I don't want to add coding style considerations at all, because
everyone is free to make them on their own anyways.

I'd be willing to help draft this section if the RFC authors so desire.
>
> Derick and Benjamin (and Sara), are these requests reasonable? If the
> RFC follows the discussion period rule and contains all the relevant
> information, I will be much more confident that it is resulting in
> the best long term outcome (and I think this would speak for many
> others on list as well).
>
> Sincerely,
> Theodore

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 3:52 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Hi,
>
> One question I'd like answered is that, like me, a few people have
> voted NO on the question to re-vote the syntax.
> If that is true, shouldn't their first primary choice be implied to be
> <<>> instead of anything else? I see 7 votes for no, but I'm the only
> one that still kept the first voting choice as <<>>.
>

At this point voting NO on the primary vote means that you are either:

1. are not ok with revolting this late in the release cycle
2. want to keep @@, because this is the current syntax (not <<>>)


> On Mon, Aug 10, 2020 at 9:40 AM Rowan Tommins 
> wrote:
> >
> > On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei 
> wrote:
> >
> > >
> > > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer <
> phpmailingli...@gmail.com>
> > > wrote:
> > >
> > >>
> > >> I have voted no because I asked a question about the ending delimiter
> and
> > >> why () didn't count. Another person asked a similar question and
> neither
> > >> of
> > >> us got a reply.
> > >>
> > >
> > > () does not count as ending symbol, because it is not required, as such
> > > its not an ending symbol.
> > >
> >
> >
> > The question asked was that _if the parentheses were made mandatory_,
> would
> > this provide the same benefits ascribed to the other syntaxes?
> >
> > To avoid repeating myself, here are the previous posts where I elaborated
> > on this question:
> >
> > * https://externals.io/message/111312#111342
> > * https://externals.io/message/111312#111354
> >
> >
> > Regards,
> > --
> > Rowan Tommins
> > [IMSoP]
>
>
>
> --
> Guilherme Blanco
> SVP Technology at Statflo Inc.
> Mobile: +1 647 232 5599
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 3:40 PM Rowan Tommins 
wrote:

> On Mon, 10 Aug 2020 at 14:08, Benjamin Eberlei 
> wrote:
>
> >
> > On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer  >
> > wrote:
> >
> >>
> >> I have voted no because I asked a question about the ending delimiter
> and
> >> why () didn't count. Another person asked a similar question and neither
> >> of
> >> us got a reply.
> >>
> >
> > () does not count as ending symbol, because it is not required, as such
> > its not an ending symbol.
> >
>
>
> The question asked was that _if the parentheses were made mandatory_, would
> this provide the same benefits ascribed to the other syntaxes?
>
> To avoid repeating myself, here are the previous posts where I elaborated
> on this question:
>
> * https://externals.io/message/111312#111342
> * https://externals.io/message/111312#111354


For me It would indeed make a slight difference, but not wanting to speak
for Theodore, I believe he did not want to add this as another option to
vote upon, when I asked him. based on the argument that new also doesn't
require () it makes sense to me.

And for me I didn't want to add it, because then we can just go back to
<<>>, which would at least be symmetrical. I.e. @@Jit() vs <>

>
>
>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 11:28 AM Peter Bowyer 
wrote:

> On Mon, 10 Aug 2020 at 10:15, Rowan Tommins 
> wrote:
>
> > I am not a fan of the @@ syntax, and respect what you're trying to do
> with
> > this RFC, but am disappointed you haven't engaged with those of us who
> said
> > that the RFC needs more detail. There is simply not enough information in
> > that table to "have an objective look", and the only other text in the
> RFC
> > makes a vague assertion about the lack of ending symbol which I still
> don't
> > understand the significance of.
> >
>
> I have voted no because I asked a question about the ending delimiter and
> why () didn't count. Another person asked a similar question and neither of
> us got a reply.
>

() does not count as ending symbol, because it is not required, as such its
not an ending symbol.

The point Andreas Leathley makes in the discussion thread about new Foo not
having an end symbol demonstrates exactly the opposite point he was trying
to make, because the new statement itself has to end with a semicolon:

new Foo();
new Foo;

A statement has an ending symbol semicolon.

Yes you can argue an attribute is metadata like "public" or "static" and
they don't have start and ending symbols either. But they are also *single*
words without special chars, as such much easier to distinguish.

The difference is also apparent in another fact: Visibility keywords are
just boolean flags on Reflection, Attributes have their own Reflection
object, they represent much more. They shouldn't be mixed up with keywords.

PHP is a language where most language constructs have ending delimiters.

- Statements end in Semicolon
- Function/Class/Method declarations end with a block closed by }
- Argument lists end with )
- Docblocks end with */
- Comments always end with EOL (the distinction here being its a single end
symbol, not ambiguous)

As such for language consistency it would be better for Attributes to be
enclosed by syntax, having a start **and* and ending symbol.


> Peter
>

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Mon, Aug 10, 2020 at 11:16 AM Rowan Tommins 
wrote:

> On Mon, 10 Aug 2020 at 09:41, Derick Rethans  wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> > [...]
> >
> > Please have a objective look at the table
> > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> > don't just go by asthetics.
> >
>
>
> Hi Derick,
>
> I am not a fan of the @@ syntax, and respect what you're trying to do with
> this RFC, but am disappointed you haven't engaged with those of us who said
> that the RFC needs more detail. There is simply not enough information in
> that table to "have an objective look", and the only other text in the RFC
> makes a vague assertion about the lack of ending symbol which I still don't
> understand the significance of.
>
> If I had a vote, I would vote "No" in the primary vote, not because I think
> the current syntax is perfect, but because I don't think this RFC makes a
> good case for a revote, and strongly suspect it will just be another beauty
> contest.
>

I am sorry this was a misunderstanding between Derick and I. I had worked
on the more detail already, but we had a miscommunication about updating
the RFC. I add my notes in a few minutes, sorry :-(

>
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Fri, Aug 7, 2020 at 2:24 AM Theodore Brown 
wrote:

> On Thu, Aug 6, 2020 at 12:30 PM Benas IML 
> wrote:
>
> > Hey Theodore,
> >
> > On Thu, Aug 6, 2020, 8:05 PM Theodore Brown 
> wrote:
> >
> > > While none of our syntax options are perfect, I believe @@ has the
> > > best long-term tradeoffs because:
> > >
> > > - It doesn't break useful syntax
> >
> > Fair enough.
> >
> > > - It is equally or more concise than grouped attributes without
> > > adding complexity to the parser/compiler
> >
> > Are we really going to debate that ~30 lines of code add complexity?
>
> Hi Benas,
>
> I don't know how many lines of code it will be, since an
> implementation for it has never been finished. The patch currently
> linked in the RFC does not implement it.
>

Curious what brings you to claim an implementation has never been finished
when it was accepted by RFC vote?

Grouping certainly has a finished implementation, Martin and I had it
working for the original RFC, then when we removed it for the original vote
had a working patch and PR as part of the Amendments RFC.

I now ported the patch to the @[] syntax PR here:
https://github.com/php/php-src/pull/5928/commits/c69e2de26c42c583a8ca0fa579c1be69d40bfc454
The zend_compile.c diff looks a bit complex, but it's really only 5 new
lines for a new for loop over the groups and all existing code one level
deeper.

All in all the attribute grouping patch adds 26 new lines (and then tests)
all restricted within the existing attribute parser rules and the functions
compiling attribute code. This adds no complexity at all.


> Even if we assume the implementation is only about 30 lines, it's
> still extra complexity that I don't understand the benefit of. I
> sincerely would like to know what advantage there is of grouped
> attributes over the `@@` syntax.
>
> - It is equally or more verbose than `@@` in real-world use cases
>

You keep bringing up verbosity like our primary language design goal is to
reduce it, PHP is the most verbose language I know. Everything in PHP
requires more characters than in other languages. Keywords are usually
long, variables need an extra $ in front. You have
to use $this-> as no implicit context exists. Functions need to be prefixed
by "array_", "str_" instead of methods on the objects.

The primary design goal of a language construct in PHP is not to reduce
verbosity.


> - Adding or removing a second attribute with grouping can require
> modifying multiple lines, adding unnecessary noise to diffs:
>
>   @@SomeAttribute("value")
>   @@AnotherAttribute("value") # can be added/removed independently
>   function foo() {}
>
>   # vs.
>
>   @[SomeAttribute("value")] # changes to:
>
>   @[
>   SomeAttribute("value"),
>   AnotherAttribute("value"), # not added/removed independently
>   ]
>   function foo() {}
>

> - How much more added complexity will the grouped syntax require if
> we add nested attributes in the future? At the least it will have to
> be special-cased in some way, either to disallow grouping for nested
> attributes or to treat the grouped syntax the same as an array.
>
`@@` avoids the need for additional complexity, special cased syntax,
> and having to modify extra lines when adding/removing separate
> attributes.
>
> > > - It is conceptually closest to the docblock syntax the PHP
> > > community is familiar with
> >
> > Well, if `@@` is similar to `@` (to me it isn't), we can say that
> > `@[]` is also similar to `@`.
>
> I would agree that `@[]` is more similar than `#[]` is. But arguably
> `@@` is still the closest since docblock annotations don't require
> being wrapped in array brackets.


But docblocks are wrapped in /** */, enclosing the whole declaration of
them.

Both @[] and #[] are comparable with /** */ as metadata **boundary**. The
attribute
itself has no symbol prefixes or alike, it's just the class name.

This is a very close translation to how docblocks with userland doc-params
work,
in my opinion this makes all enclosed syntaxes much more in line with
existing syntax,
regardless of symbols used.


> > > - It is aligned with the attribute semantics of the majority of C
> > > family languages
> >
> > In what way `#[]` or `@[]` aren't?
>
> The majority of C family languages use `@Attr` without an extra end
> symbol. This makes sense since attributes are simply metadata
> modifying the declaration that follows them, similar to visibility
> and type declarations.
>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Thu, Aug 6, 2020 at 9:18 AM Côme Chilliet <
come.chill...@fusiondirectory.org> wrote:

> Le Thu, 6 Aug 2020 07:48:05 +0100 (BST),
> Derick Rethans  a écrit :
> > From the RFC:
> > - No ending delimiter
>
> As said before, it does have an ending delimiter when they are arguments
> since
>  there is the parenthesis around them. When there are no arguments I don’t
> see
>  the benefit of an ending delimiter, it’s easy to spot the end of the word.
>
> > - Doesn't allow grouping
>
> I do not understand this argument, what is the point of grouping for @@?
> Does grouping mean anything special for other syntaxes, or is it just to
> save
>  keystrokes? If it is just to get a more concise syntax when there are
> several
>  attributes, the fact that @@ do not need grouping is a pro, not a con.
>
> > - No forwards compat with PHP 7
>
> But no BC break either, while #[] introduces BC break.
>

This is **not** true. Both @@ and #[  will break existing PHP 7 code!

The question is how likely each of them is. #[ will be slightly higher than
@@ - but both will still be in the 0,01% range of occurrences.

and for *both* the same Fix is a project wide sed that replaces @@ with
@@ and #[ with #[ respectively.


> > - Not used ny another language
>
> @ is used by a lot of other languages, and @@ is the closest we can get in
> PHP.
>
> Côme
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Tue, Aug 4, 2020 at 6:37 PM Theodore Brown 
wrote:

> On Tue, Aug 4, 2020 at 8:45 AM Derick Rethans  wrote:
>
> > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> > Syntax Change RFC to reflect that process:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
> >
> > Patches and comments welcome.
>
> Hi Derick,
>
> I don't agree with the main argument put forward in this RFC:
>
> > The main concern is that @@ has no ending symbol and it's
> > inconsistent with the language that it would be the only
> > declaration or statement in the whole language that has no ending
> > termination symbol.
>
> Attributes are not a standalone statement or declaration; they are
> metadata *on* a declaration. They cannot stand alone, but always
> modify the following declaration, just as public and static modify
> a method, or a type declaration modifies a parameter or property.
>
> Modifying declarations (e.g. for visibility and type) do not have an
> ending symbol. For example, we don't write something like:
>
> [public] function foo([int] $bar) {}
>
> With the @@ syntax attributes a treated consistently with type and
> visibility declarations:
>
> @@Jit
> public function foo(@@Deprecated int $bar) {}
>
> So there is nothing inconsistent about not having a termination
> symbol - this is in harmony with visibility and type declarations in
> PHP, as well as the attribute syntax used by a majority of C family
> languages. [1]
>

Attributes are potentially way more complex than a visibility keyword. As
such it is a reasonable requirement to say they should have a unified
ending symbol, or more broadly speaking that attributes should be enclosed
by syntax.

It looks nice for a simple attribute like @@Jit, or for a one without
arguments like the used @@Deprecated, but as soon as there are more than
one, and they each get arguments, enclosing them has its own benefits over
them just standing for themselves.

>
> When it comes to supporting attribute grouping, I actually consider
> this a downside of the #[], @[], and <<>> syntaxes. It complicates
> the internal implementation, and makes it so developers have to
> choose between two different syntaxes when adding more than one
> attribute. In real-world use cases the @@ syntax is just as or even
> more concise without the extra parser/compiler complexity:
>
> #[Attr1, Attr2] # 15 chars
>
> @@Attr1 @@Attr2 # 15 chars
>
> # 4 lines, 53 chars not counting whitespace
> @[
> AttrWithParam("foobar"),
> SomeOtherAttr("fizzbuzz"),
> ]
>
> # 2 lines, 52 chars
> @@AttrWithParam("foobar")
> @@SomeOtherAttr("fizzbuzz")
>
> I agree that we want the best syntax, not necessarily the best
> **looking** syntax. I still believe that the @@ syntax offers the best
> balance here. It's familiar, concise without additional complexity,
> and doesn't break useful syntax the way @[] and #[] do.
>

Yes, we have been doing this for 20 years, adding annotations enclosed with
/** and */ with each enclosing on its own line for the most part. We even
added stars in front of every inbetween line.

we are stepping into unchartered territory here with @@ by our standards as
PHP community. Using "C familiy" as an argument that they made @ work does
not mean much, because the language itself is just the "interface" to the
implementation, each C family language probably has vastly different
parsers, concerns and approaches. It should be right for PHP.


> Kind regards,
> Theodore
>
> [1]:
> https://wiki.php.net/rfc/shorter_attribute_syntax#comparison_to_other_languages
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Tue, Aug 4, 2020 at 4:19 PM David Rodrigues 
wrote:

> Suggestions:
>
> $(Attribute()) (available)
> $[Attribute()] (available)
> <> 2)>> (like strings escapes)
>

I had someone else suggest $[] to me today as well, funny coincidence :-)

Can you take the "@@ to @[] pull" request as a starting point to try if
this works with a patch?

https://github.com/php/php-src/pull/5928

This syntax is "not" familiar with docblock usage of @, as it doesn't
contain a @ :-D
It does pose difficulty for static analyers and userland parsers, because
they see the $ as a T_VARIABLE
in PHP 7.


> About $() syntax:
>
>- Number of required characters: (2+1)
>- Has end delimiter: yes
>- Allow grouping: yes
>- Forward compatibility in PHP 7: yes
>- Breaks BC of valid PHP 7 codes: no
>- Used by other languages: no?
>- Familiar with Docblock Usage: I don't know
>- Difficulties with Userland Parsers: I don't know
>
> And my another suggestion is use a more verbose for now, until we have a
> good consensus about it "using attribute()":
>
>
>- Number of required characters: (16+1)
>
>
>- Has end delimiter: yes
>
>
>- Allow grouping: yes
>
>
>- Forward compatibility in PHP 7: yes
>
>
>- Breaks BC of valid PHP 7 codes: no
>
>
>- Used by other languages: no?
>
>
>- Familiar with Docblock Usage: I don't know
>
>
>- Difficulties with Userland Parsers: I don't know
>
>
This would definitely need a fully working patch to be a contender in the
vote.

- It's not forward compatibltle with PHP 7, because use of the syntax
would  lead to a fatal error on PHP 7 parsers or am I seeing something
wrong?
- its not a familiar syntax for PHP developers used to @ in docblocks

>
> Atenciosamente,
> David Rodrigues
>
>
> Em ter., 4 de ago. de 2020 às 11:03, Benjamin Eberlei 
> escreveu:
>
>> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:
>>
>> > Hi,
>> >
>> > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
>> > Syntax Change RFC to reflect that process:
>> >
>> > https://wiki.php.net/rfc/shorter_attribute_syntax_change
>> >
>> > Patches and comments welcome.
>> >
>> > FWIW, this has an excemption from the RM Sara as per [2]:
>> >
>> > > * Shorter Attribute Syntax Change
>> > >- Joe/Derick - Please make sure this RFC moves along and reaches
>> > >  conclusion by beta3, as discussed previously.
>> >
>>
>> In combination to the existing proposals we already voted one, this RFC
>> includes a fourth option that has not been discussed before,
>> and could be the compromise we are all looking for :-)
>>
>> @[Attr] combines both the with to use the familiar @ of many, and the wish
>> to have a closing symbol/termination symbol that many others have.
>>
>> It does not have the downsides that Tyson found w.r.t. to #[Attr] being
>> interpreted as comment on PHP 7, but that also means its not forward
>> compatible like #[Attr] is.
>>
>> It provides a small BC break where code written as @[$foo, $bar] = baz();
>> or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that
>> can
>> be easily
>> fixed by writing it with a space between @ and [.
>>
>>
>> >
>> > cheers,
>> > Derick
>> >
>> > [1] https://externals.io/message/111218#111261
>> > [2] https://externals.io/message/111286#111286
>> >
>> > --
>> > PHP 7.4 Release Manager
>> > Host of PHP Internals News: https://phpinternals.news
>> > Like Xdebug? Consider supporting me: https://xdebug.org/support
>> > https://derickrethans.nl | https://xdebug.org | https://dram.io
>> > twitter: @derickr and @xdebug
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: https://www.php.net/unsub.php
>> >
>> >
>>
>

Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2

[Benjamin Eberlei]

On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans  wrote:

> Hi,
>
> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
> Syntax Change RFC to reflect that process:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change
>
> Patches and comments welcome.
>
> FWIW, this has an excemption from the RM Sara as per [2]:
>
> > * Shorter Attribute Syntax Change
> >- Joe/Derick - Please make sure this RFC moves along and reaches
> >  conclusion by beta3, as discussed previously.
>

In combination to the existing proposals we already voted one, this RFC
includes a fourth option that has not been discussed before,
and could be the compromise we are all looking for :-)

@[Attr] combines both the with to use the familiar @ of many, and the wish
to have a closing symbol/termination symbol that many others have.

It does not have the downsides that Tyson found w.r.t. to #[Attr] being
interpreted as comment on PHP 7, but that also means its not forward
compatible like #[Attr] is.

It provides a small BC break where code written as @[$foo, $bar] = baz();
or $foo = @["bar" => $baz]; will not compile on PHP 8 anymore, but that can
be easily
fixed by writing it with a space between @ and [.


>
> cheers,
> Derick
>
> [1] https://externals.io/message/111218#111261
> [2] https://externals.io/message/111286#111286
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] Re: @@Jit Attribute Considerations

[Benjamin Eberlei]

On Mon, Aug 3, 2020 at 7:44 PM Benjamin Eberlei  wrote:

> Hi,
>
> I am going to pick up a discussion from
> https://github.com/php/php-src/pull/5915 about the @@Jit attribute.
>
> Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
> attribute and asked to discuss here.
>
> The reason is that the default tracing JIT is clever to decide itself when
> to JIT or not, better not interfere with that. In case you run the tracing
> JIT, only @@Jit("off") has an effect the others @@Jit("tracing") and
> @@Jit("function") get ignored.
>
> Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> and "function". This trigger mode feels like micro-management for
> developers and since it has virtually no spotlight in discussions and blog
> posts about the JIT at the moment, we don't know if it brings benefits.
>
> Maybe for now it would be better to remove docblock / attribute support
> for the JIT, and take a new attempt at it in 8.1? That prevents us from
> rolling something we regret having to maintain later.
>

I updated the PR https://github.com/php/php-src/pull/5915 with the
following things:

- Removed attribute trigger mode for now.
- Removed obsolete doc comment trigger mode
- Add @@Jit("off") to disable JIT for an op_array or script

Open questions:
- Are we ok with removing @Jit("on"), @@Jit("tracing") and
@@Jit("function") for now to thoroughly discuss best approach for 8.1?
- Rename @@Jit to something more specific like @@JitOptions or @@JitHint?
- Remove the attribute trigger constant 4, and move tracing JIT to use 4
instead of 5?

Outlook:

We need to think about what the @@Jit attribute should actually mean in
context of the function or tracing JIT. Personally it probably means
"Always Jit this function regardless of hot counter or tracing results".
I believe we don't need the attributes trigger mode, as everything happens
either in context of function or tracing JIT.


> greetings
> Benjamin
>

Re: [PHP-DEV] @@Jit Attribute Considerations

[Benjamin Eberlei]

Alternatively make it @@Jit("off") only and any other argument will lead to
an error for now.

Then the problem left becomes "Jit" being a very short global class.

On Mon, Aug 3, 2020 at 10:36 PM Benas IML  wrote:

> `@@NoJit` sounds pretty alright to me.
>
> On Mon, Aug 3, 2020, 11:27 PM Derick Rethans  wrote:
>
>> On 3 August 2020 20:20:35 BST, Benjamin Eberlei 
>> wrote:
>>
>> >In that case maybe we should rename the attribute to @@DisableJit ?
>> >This
>> >would not clutter the global namespace with a "jit" class.
>>
>> Things with a negative name are usually a code smell. I'm not keen on a
>> @[disableJit] attribute name.
>>
>> cheers,
>> Derick
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>
>>

Re: [PHP-DEV] @@Jit Attribute Considerations

[Benjamin Eberlei]

On Mon, Aug 3, 2020 at 8:51 PM Stanislav Malyshev 
wrote:

> Hi!
>
> > Only the trigger mode 4 (attributes) is actually using @@Jit("tracing")
> and
> > "function". This trigger mode feels like micro-management for developers
> > and since it has virtually no spotlight in discussions and blog posts
> about
> > the JIT at the moment, we don't know if it brings benefits.
>
> I think turning JIT off is a valid use case, the rest looks much more
> iffy. I am not sure we want to let people tell the engine to JIT certain
> functions - are there a lot of cases where the engine wouldn't do it but
> it's actually the right thing to do?
>

In that case maybe we should rename the attribute to @@DisableJit ? This
would not clutter the global namespace with a "jit" class.

>
> Don't see any use for "opcache.jit=attributes".
>
> --
> Stas Malyshev
> smalys...@gmail.com
>

[PHP-DEV] @@Jit Attribute Considerations

[Benjamin Eberlei]

Hi,

I am going to pick up a discussion from
https://github.com/php/php-src/pull/5915 about the @@Jit attribute.

Nikita mentioned he is still not 100% clear what the usecase is for @@Jit
attribute and asked to discuss here.

The reason is that the default tracing JIT is clever to decide itself when
to JIT or not, better not interfere with that. In case you run the tracing
JIT, only @@Jit("off") has an effect the others @@Jit("tracing") and
@@Jit("function") get ignored.

Only the trigger mode 4 (attributes) is actually using @@Jit("tracing") and
"function". This trigger mode feels like micro-management for developers
and since it has virtually no spotlight in discussions and blog posts about
the JIT at the moment, we don't know if it brings benefits.

Maybe for now it would be better to remove docblock / attribute support for
the JIT, and take a new attempt at it in 8.1? That prevents us from rolling
something we regret having to maintain later.

greetings
Benjamin

Re: [PHP-DEV] PR: Bump libxml version, deprecate libxml_disable_entity_loader()

[Benjamin Eberlei]

Hi Dik,

your e-mail has likely been going to spam for many subscribers of the
mailing list, I have just seen it after reading Nikitas comment on the PR.

https://github.com/php/php-src/pull/5867

I am all for this and wanted to bump the thread to the list so that
everyone can see this as well.

Are there objections from anyone from merging this on Monday?

greetings
Benjamin

On Thu, Jul 16, 2020 at 5:48 PM Dik Takken  wrote:

> Hi internals,
>
> I prepared a PR which aims to properly fix a long standing problem
> related to secure XML processing in PHP.
>
> In short, it bumps the minimum required version of libxml and it
> deprecates the libxml_disable_entity_loader() function.
>
> You can find the details in the PR:
>
> https://github.com/php/php-src/pull/5867
>
> Please have a look.
>
> Thanks,
>
> Dik Takken
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Benjamin Eberlei]

On Thu, Jul 30, 2020 at 6:19 PM guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Question: The key factor of not using @ is due to conflict of
> suppression symbol.
> While we are in a major (where BC breaks are not encourage, but
> tolerable), have we considered the possibility of BC breaking
> suppression symbol (@ would become @@) and using @ for Attributes?
>

no chance, it needs at lesat 1 major release of deprecation before a syntax
should be reusable for something else.

>
> I bet a search/replace wouldn't be that hard to be achieved, and it
> would function even today (as @@ is acceptable). Basically, it's a BC
> break where code needs to be changed, but backwards compatible as new
> suppressor symbol is backwards compatible with previous versions of
> PHP.
>

> Just some food for thought
>
> On Thu, Jul 30, 2020 at 11:57 AM Rowan Tommins 
> wrote:
> >
> > On Thu, 30 Jul 2020 at 14:28, Joe Ferguson  wrote:
> >
> > > ... I'm still here wanting us to talk about the
> > > impact of @@ on static analysis tools. Apparently, internals doesn't
> care
> > > about these projects.
> > >
> >
> >
> > I don't think that's a reasonable summary of this thread at all. I've
> seen
> > three main types of response:
> >
> > 1) "I haven't followed the discussion about PHPCS, please could you
> > summarise the problem."
> > 2) "I don't understand why tools running on PHP 7.x need to parse PHP 8.x
> > syntax."
> > 3) "I think #[] will cause as many problems for such tools as @@, just in
> > different places."
> >
> > Maybe they weren't always as polite or succinct as that, but not agreeing
> > with you is not the same as not caring.
> >
> >
> > As far as I can make out, attributes that appear entirely on a single
> line
> > with no other text are trivial to ignore in any parser whatever the
> syntax.
> > That trivial case is slightly more trivial with #[] because a PHP 7
> parser
> > will treat it as a line comment; but add a rule to your parser to also
> > treat "@@" as a line comment, and you're done.
> >
> > The problems come when you have a) an attribute definition spanning
> > multiple lines, and/or b) an attribute definition inline with other code.
> > As soon as you have that, you have no choice but to parse the code
> entirely
> > according to the grammar of PHP 8, not as "PHP 7 with some warts".
> >
> > If detecting the end of annotation tokens is really that difficult, would
> > it suffice to make the () mandatory (i.e. @@Deprecated() rather than
> > @@Deprecated)? The rules for what could appear between @@ and ( are
> pretty
> > simple, and finding the correct ending ) should be pretty much the same
> > effort as finding the correct ending ], since both can occur in matching
> > pairs inside the argument list.
> >
> > Regards,
> > --
> > Rowan Tommins
> > [IMSoP]
>
>
>
> --
> Guilherme Blanco
> SVP Technology at Statflo Inc.
> Mobile: +1 647 232 5599
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Benjamin Eberlei]

I think it has become clear that we need to revisit this syntax question
again, including the elephpant in the room of delaying this feature to 8.1.

The reason is not only Joe's desire to revote on #[], but also that there
are now more syntax proposals such as @[] by Derick or @@ in comments by
Tyson (though no patch exists for it yet). At this point a lot of syntaxes
are potentially viable (except single @, please don't suggest it).

I feel the choice between many syntaxes is 80% subjective, 20% objective
facts, so tensions are to be expected.

As the author of the original RFC and patch, I hope I have some klout in
suggesting the following procedure (RMs would need to extend their approval
for revote to this).

1. we collect syntax proposals once again, with the requirement of a simple
patch being available against php-src/master for viability in 8.0.

2. RMs are the arbiter to decide the patch is acceptable to be included for
8.0 or if its selection would delay entire attributes to 8.1.

3. I would make a feature matrix for the vote / RFC page and sort each
proposed syntax into it, seeking input from the proposers.

4. We would then hold another vote on syntax using STV where the choice is
a combination of syntax and target version, examples:

- <<>> in 8.0, #[] in 8.0, @@ in 8.0 (all these patches are viable)
- @@ in doc blocks for 8.1
- §[] in 8.1 (weird example to demonstrate the point)

and so on. The STV vote would run with potentially 5-10 different syntaxes.

On Time Frame: Sara allowed to extend this decision into feature freeze,
but I believe it shouldn't be later than Beta 2 (August 20th), especially
if the outcome could be delay until 8.1.

What do RMs think of voting from 10th to 17th of August, giving us 3 days
to merge. This gives everyone until August 8-9th to work on their syntax
proposal.

greetings
Benjamin

On Tue, Jul 28, 2020 at 4:47 PM Joe Ferguson  wrote:

> Hello Internals,
>
> I've been working with Derick Rethans and others (thanks all!) on a Shorter
> Attribute Syntax Change RFC which outlines reasons why the "#[]" syntax
> would be preferred over the currently agreed upon "@@" syntax for Shorter
> Attribute Syntax.
>
> An important part of the research that went into this proposal demonstrates
> how "@@" will make handling attributes more difficult for PHP_CodeSniffer
> (and similar tools) and shows how the alternative "#[]" syntax is more
> friendly for these tools.
>
> You can find the RFC
> https://wiki.php.net/rfc/shorter_attribute_syntax_change and I'm happy to
> answer any questions as best I can.
>
> --
> - Joe Ferguson
> JoeFerguson.me
> osmihelp.org
>

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

[Benjamin Eberlei]

Hi Joe,

Personally I favor #[] myself, but there has been a vote with a substantial
participation choosing @@. Overturning this democratic outcome should
require **significant** technical arguments, otherwise this RFC would
provide problematic precedent for any RFC to be overturned by arbitrary
revoting.

The arguments the RFC brings forward don't convince me that we should pick
#[] over @@.

1. The parser conflict was my major reason why @@ should not have been
picked from a technical POV. But this issue has been fixed by an
independent improvement since then. These kinds of small problems are found
regularly after RFCs are accepted and are subsequently fixed. The RFC is
formulated as the problem still exists, but it does not. Yes, the namespace
token RFC vote has not yet finished, but there is no chance it will be
rejected at this point.

Since the namespace token RFC is passing, and I have seen the simplicity of
the new parser rules, my opinion has changed to keep pushing for #[] and I
accept the @@ outcome.

2. The phpcs argument also does not convince me.

Summed up it is essentially that a current version of phpcs does not
support parsing @@ or <<>> yet and incorrectly changes code using them,
however for #[] it does nothing because it parses it as a comment. To me
this sounds like a bug in PHPCS. This argument also breaks down completely
on multi line attributes.

Why should we even expect PHPCS to support an unreleased version? If
someone uses PHP 8 code, why do we assume they keep using an old version of
phpcs that does not support PHP 8 yet?

3. We already established that the syntax question is extremely
contentious, and I was getting tons of messages on it on Twitter, Reddit,
Email et al during the initial Attributes RFC. So of course people would be
against @@ (as I am myself), however it had a majority in votes.

For me putting these subjective opinions into the RFC makes the case for
overturning less convincing, because it makes the argument that overturning
a valid democratic vote is somehow OK if you are loud.

The only reason why we change this outcome must be purely technical imho.

4. You cannot write a regex to detect the end symbols for both #[] or <<>>,
because both end symbols are allowed *inside* the attribute syntax already,
so it's not easier to find occurrences with regexes with the other syntaxes:

#[Foo([1 => 2])]
<> 4)>>

Simple detection of attributes will always need to grep only for the start
token, and both @@ and #[ are equally unique to find here.

5. For readability an end token would be nicer (which is why i prefer #[]).
But this information was already known during the first vote on the syntax
and rejected by majority.

6. An end token might indeed allow extending attributes with new stuff, but
nobody has brought up this use-case before. No other language has
additional attribute keywords, why is this brought as a positive argument,
when the choice of syntax no other language uses is brought up as a
negative point later?

7. Future potential parsing problems are brought forward for @@, but #
being a comment token makes it likely that #[] will also cause problems.
Tyson has a few examples in his email to this thread.

Other confusing things you can do with #[] for example:

#[Foo( 1 # 1 ] bar
)]
function foo () { }

Which is #[Foo(1)] without comments and line breaks.

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

[Benjamin Eberlei]

On Sun, Jul 26, 2020 at 3:52 PM Chris Riley  wrote:

> Hi all,
>
> Thanks for the feedback so far. In light of the feedback received both here
> and privately, I've made 3 changes to the RFC document:
>
> 1. The original option 1, allowing renaming parameters but not requiring an
> explicit opt in to enable them to be called by name has been dropped. The
> proposal is now only for explicit opt in parameters with renaming as a
> possibility. The reasoning for this, is that although I included option 1
> as I thought it might be more likely to be accepted; many people pointed
> out that we are very close to the cutoff date for PHP 8.0 and that
> implementing such a change would likely be too big to get done in time.
> Option 1 would be possible to include in PHP 8.1 as it doesn't break BC,
> this means that the proposal can be brought back targeting 8.1 should
> option 2 not be accepted
>

Can you clarify if opt-in would only be the behavior on userland functions,
or if all internal functions would also change to opt-in?

If no, then the inconsistency must be explained.
if yes then the next steps for each internal API to decide on allowing
named params or not needs to be explained

Both approaches lead to a lot of problems down the road that were nicely
circumvented by auto-optin of all functions.

Implementation wise, with external name, you have only one name on the call
site. That means if you decide to rename an argument,
then you cannot support both the old and the new name for one major release
cycle to allow your users to upgrade smoothly.
As such it is my opinion that this is an inferior approach to having an
alias that allows declaring a second name.

Have you given an E_NOTICE/E_WARNING a thought? A user of a library could
then overwrite a library authors "with" to disallow named parameters.

Can you add an example how the MessageHandler problem would look like with
your proposal? Is the external name inherited? Is it forced to inherit? Can
it be overwritten?


> 2. With respect to the feature freeze date, I've added a possible strategy
> to deal with a staged implementation, should the release managers not feel
> comfortable including the full feature at this late stage.
>

Can you update the Proposed Voting Choices section with the two questions
for the staged implementation? or the one question combining them both? The
wording is going to be signifcant for further discussion.


> 3. I have documented the main objections to the RFC on the RFC itself and
> included my rebuttals; should anyone feel I've not represented their point
> fairly let me know and I'll update.
>

Your "objections" section mentions the inheritance / polymorphism part
being buried/hidden in the RFC, but its a section on its own
https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance
and Nikita sent several mails to the list about this topic, asking for
specific feedback about this outstanding issue alone.

The main change in your RFC from explicitly enabled for all userland and
internal functions to an opt-in approach for userland functions was also
discussed in depth.

Similar approaches to your suggestions were also mentioned again in the RFC
prominently under "Alternatives", overruled by the voted upon
implementation that got 76% acceptance.


>
> Regards,
> Chris
>

At this point I would much prefer to discuss amendments within the current
behavior and not against it.

My counter-proposal is still to have two, potentially three attributes:

- @@NameAlias to define a second name/alias for a parameter. Would help
solve both polymorphic name changes and refactoring of names.
- @@PositionalArgumentsOnly to define on a function or class, throwing an
exception if used with named arguments. This only slightly makes the use
case of named arguments slower.

Maybe the reverse with @@NamedArgumentsOnly - however checking for that
would probably slightly make all positional calls slower, which will
probably stay the primary way of calling functions. Trade offs are unclear
here.

I know attributes "feel" wrong here, being a new feature and not been used
for anything yet in the language. But attributes have the benefit of not
introducing new keywords or syntax to the language and are the right tool
to "re-configure" a feature from its primary behavior. Use of attributes
would also keep open future changes (by introducing new attributes or
arguments to the existing ones) leaving our options open instead of locking
them down further.


> On Fri, 24 Jul 2020 at 12:12, Chris Riley  wrote:
>
> > Hi all,
> >
> > The named parameters RFC has been accepted, despite significant
> objections
> > from maintainers of larger OSS projects due to the overhead it adds to
> > maintaining backwards compatibility as it has now made method/function
> > parameter names part of the API; a change to them would cause a BC break
> > for any library users who decide to use the new feature.
> >
> > It is likely that the way this will shak

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

[Benjamin Eberlei]

On Fri, Jul 24, 2020 at 4:00 PM Chris Riley  wrote:

> Hi all,
>
> Following up from this I've created a draft RFC:
> https://wiki.php.net/rfc/renamed_parameters will move to in discussion
> once
> I've ensured everything important has been captured.
>
> Regards,
> Chris
>

You added PHP 8.0 as a propsoed version, but that will not be possible
anymore 2 weeks of discussion + 2 weeks of voting are not possible to fit
in before the feature freeze, which is in 11 days.

>
> On Fri, 24 Jul 2020 at 12:12, Chris Riley  wrote:
>
> > Hi all,
> >
> > The named parameters RFC has been accepted, despite significant
> objections
> > from maintainers of larger OSS projects due to the overhead it adds to
> > maintaining backwards compatibility as it has now made method/function
> > parameter names part of the API; a change to them would cause a BC break
> > for any library users who decide to use the new feature.
> >
> > It is likely that the way this will shake out is that some maintainers
> > will accept the additional overhead of including parameter names in their
> > BC guidelines and others will not, this leaves users unsure if they can
> use
> > the new feature without storing up issues in potentially minor/security
> > releases of the libraries they use. This is not really an ideal
> situation.
> >
> > More pressing a point is that the current implementation breaks object
> > polymorphism. Consider this example (simplified from one of my codebases)
> >
> > interface Handler {
> > public function handle($message);
> > }
> >
> > class RegistrationHandler implements Handler {
> > public function handle($registraionCommand);
> > }
> >
> > class ForgottenPasswordHandler implements Handler {
> > public function handle($forgottenPasswordCommand);
> > }
> >
> > class MessageBus {
> > //...
> > public function addHandler(string $message, Handler $handler) {
> //... }
> > public function getHandler(string $messageType): Handler { //... }
> > public function dispatch($message)
> > {
> > $this->getHandler(get_class($message))->handle(message:
> $message);
> > }
> > }
> >
> > This code breaks at run time.
> >
> > Proposals were made for resolutions to this issue however all of them
> > require trade offs and could potentially break existing code.
> >
> > My proposal to resolve these two issues is to add the ability to rename
> > parameters with a new syntax as follows.
> >
> > function callBar(Foo $internalName:externalName) {
> > $internalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x);
> >
> > This allows both the above problems to be resolved, by renaming the
> > internal parameter and keeping the external signature the same.
> >
> > I propose that the RFC would have two voting options.
> >
> > The first would be to implement it as proposed above, this would allow
> any
> > parameter to be called by name regardless of the intentions of the author
> > of the method/function and is closest to the current behaviour.
> >
> > The second option would be to use this syntax to make named parameters in
> > userland code explicitly opt in. As such an additional shortcut syntax
> > would be implemented: $: to designate a named parameter. eg
> >
> > function callBar($:externalName) {
> > $externalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x);
> >
> > If a parameter is not opted in, a compile time error is raised:
> >
> > function callBar($externalName) {
> > $externalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x); // Error: cannot call parameter $externalName
> > by name.
> >
> > There are pros and cons to this second approach, on the one hand it
> > reduces the usefulness of the named parameter syntax by requiring changes
> > to old code to enable it (although this could probably be automated
> fairly
> > easily) however it does provide a neater solution to the second problem
> in
> > that, to prevent the runtime errors in the second issue example, every
> > child class would need to use the rename syntax on it's parameter to
> > prevent errors, whereas if we went down this route, the parent class
> could
> > just not opt into the named parameter syntax and the code would function
> as
> > expected.
> >
> > Another advantage is that with the ability to rename parameters using the
> > opt in, we gain some flexibility to tighten up the LSP rules relating to
> > named parameter inheritance.
> >
> > class Foo {
> > public function bar($:param) { //... }
> > public function baz($internal:external) { //... }
> > }
> >
> > // OK
> > class Bar {
> > public function bar($renamed:param) { //... }
> > public function baz($renamed:external) { //... }
> > }
> >
> > // Compile time error cannot rename named parameter $:param (renamed to
> > $:renamedParam)
> > class Baz {
> > public function bar($:renamedParam) { //... }
> > }
> >
> > // Compile time error cannot rename named parameter $:external

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Benjamin Eberlei]

On Fri, Jul 24, 2020 at 3:15 PM Chris Riley  wrote:

> On Fri, 24 Jul 2020 at 14:01, Benjamin Eberlei 
> wrote:
>
>>
>>
>> On Fri, Jul 24, 2020 at 1:13 PM Chris Riley  wrote:
>>
>>> Hi all,
>>>
>>> The named parameters RFC has been accepted, despite significant
>>> objections
>>> from maintainers of larger OSS projects due to the overhead it adds to
>>> maintaining backwards compatibility as it has now made method/function
>>> parameter names part of the API; a change to them would cause a BC break
>>> for any library users who decide to use the new feature.
>>>
>>
>> Hi Chris,
>>
>> I had something similar in mind, but using an attribute. Here is a patch
>> that already allows this:
>>
>>
>> https://github.com/beberlei/php-src/commit/4b0a02f9c6ba579f93ec57c754fa3794a96c696b
>>
>> Idea: Have a @@NameAlias attribute, where you can provide a second name
>> for the attribute. This would allow to refactor parameter names by adding
>> the attribute with the old name as an alias.
>>
>>
>>>
>>> It is likely that the way this will shake out is that some maintainers
>>> will
>>> accept the additional overhead of including parameter names in their BC
>>> guidelines and others will not, this leaves users unsure if they can use
>>> the new feature without storing up issues in potentially minor/security
>>> releases of the libraries they use. This is not really an ideal
>>> situation.
>>>
>>> More pressing a point is that the current implementation breaks object
>>> polymorphism. Consider this example (simplified from one of my codebases)
>>>
>>> interface Handler {
>>> public function handle($message);
>>> }
>>>
>>> class RegistrationHandler implements Handler {
>>> public function handle($registraionCommand);
>>> }
>>>
>>> class ForgottenPasswordHandler implements Handler {
>>> public function handle($forgottenPasswordCommand);
>>> }
>>>
>>> class MessageBus {
>>> //...
>>> public function addHandler(string $message, Handler $handler) {
>>> //... }
>>> public function getHandler(string $messageType): Handler { //... }
>>> public function dispatch($message)
>>> {
>>> $this->getHandler(get_class($message))->handle(message:
>>> $message);
>>> }
>>> }
>>>
>>> This code breaks at run time.
>>>
>>> Proposals were made for resolutions to this issue however all of them
>>> require trade offs and could potentially break existing code.
>>>
>>> My proposal to resolve these two issues is to add the ability to rename
>>> parameters with a new syntax as follows.
>>>
>>> function callBar(Foo $internalName:externalName) {
>>> $internalName->bar();
>>> }
>>>
>>> $x = new Foo();
>>> callBar(externalName: $x);
>>>
>>> This allows both the above problems to be resolved, by renaming the
>>> internal parameter and keeping the external signature the same.
>>>
>>> I propose that the RFC would have two voting options.
>>>
>>> The first would be to implement it as proposed above, this would allow
>>> any
>>> parameter to be called by name regardless of the intentions of the author
>>> of the method/function and is closest to the current behaviour.
>>>
>>> The second option would be to use this syntax to make named parameters in
>>> userland code explicitly opt in. As such an additional shortcut syntax
>>> would be implemented: $: to designate a named parameter. eg
>>>
>>> function callBar($:externalName) {
>>> $externalName->bar();
>>> }
>>>
>>> $x = new Foo();
>>> callBar(externalName: $x);
>>>
>>> If a parameter is not opted in, a compile time error is raised:
>>>
>>> function callBar($externalName) {
>>> $externalName->bar();
>>> }
>>>
>>> $x = new Foo();
>>> callBar(externalName: $x); // Error: cannot call parameter $externalName
>>> by
>>> name.
>>>
>>> There are pros and cons to this second approach, on the one hand it
>>> reduces
>>> the usefulness of the named parameter syntax by requiring changes to old
>>> code to enable it (although this could probably be automated fairly
>>> easily)

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Benjamin Eberlei]

On Fri, Jul 24, 2020 at 1:13 PM Chris Riley  wrote:

> Hi all,
>
> The named parameters RFC has been accepted, despite significant objections
> from maintainers of larger OSS projects due to the overhead it adds to
> maintaining backwards compatibility as it has now made method/function
> parameter names part of the API; a change to them would cause a BC break
> for any library users who decide to use the new feature.
>

Hi Chris,

I had something similar in mind, but using an attribute. Here is a patch
that already allows this:

https://github.com/beberlei/php-src/commit/4b0a02f9c6ba579f93ec57c754fa3794a96c696b

Idea: Have a @@NameAlias attribute, where you can provide a second name for
the attribute. This would allow to refactor parameter names by adding the
attribute with the old name as an alias.


>
> It is likely that the way this will shake out is that some maintainers will
> accept the additional overhead of including parameter names in their BC
> guidelines and others will not, this leaves users unsure if they can use
> the new feature without storing up issues in potentially minor/security
> releases of the libraries they use. This is not really an ideal situation.
>
> More pressing a point is that the current implementation breaks object
> polymorphism. Consider this example (simplified from one of my codebases)
>
> interface Handler {
> public function handle($message);
> }
>
> class RegistrationHandler implements Handler {
> public function handle($registraionCommand);
> }
>
> class ForgottenPasswordHandler implements Handler {
> public function handle($forgottenPasswordCommand);
> }
>
> class MessageBus {
> //...
> public function addHandler(string $message, Handler $handler) { //... }
> public function getHandler(string $messageType): Handler { //... }
> public function dispatch($message)
> {
> $this->getHandler(get_class($message))->handle(message: $message);
> }
> }
>
> This code breaks at run time.
>
> Proposals were made for resolutions to this issue however all of them
> require trade offs and could potentially break existing code.
>
> My proposal to resolve these two issues is to add the ability to rename
> parameters with a new syntax as follows.
>
> function callBar(Foo $internalName:externalName) {
> $internalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> This allows both the above problems to be resolved, by renaming the
> internal parameter and keeping the external signature the same.
>
> I propose that the RFC would have two voting options.
>
> The first would be to implement it as proposed above, this would allow any
> parameter to be called by name regardless of the intentions of the author
> of the method/function and is closest to the current behaviour.
>
> The second option would be to use this syntax to make named parameters in
> userland code explicitly opt in. As such an additional shortcut syntax
> would be implemented: $: to designate a named parameter. eg
>
> function callBar($:externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> If a parameter is not opted in, a compile time error is raised:
>
> function callBar($externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x); // Error: cannot call parameter $externalName by
> name.
>
> There are pros and cons to this second approach, on the one hand it reduces
> the usefulness of the named parameter syntax by requiring changes to old
> code to enable it (although this could probably be automated fairly easily)
> however it does provide a neater solution to the second problem in that, to
> prevent the runtime errors in the second issue example, every child class
> would need to use the rename syntax on it's parameter to prevent errors,
> whereas if we went down this route, the parent class could just not opt
> into the named parameter syntax and the code would function as expected.
>
> Another advantage is that with the ability to rename parameters using the
> opt in, we gain some flexibility to tighten up the LSP rules relating to
> named parameter inheritance.
>
> class Foo {
> public function bar($:param) { //... }
> public function baz($internal:external) { //... }
> }
>
> // OK
> class Bar {
> public function bar($renamed:param) { //... }
> public function baz($renamed:external) { //... }
> }
>
> // Compile time error cannot rename named parameter $:param (renamed to
> $:renamedParam)
> class Baz {
> public function bar($:renamedParam) { //... }
> }
>
> // Compile time error cannot rename named parameter $:external (renamed to
> $:renamed)
> class Baz {
> public function baz($internal:renamed) { //... }
> }
>
> While this would be technically possible with the first option (no opt in)
> it would break any existing code which renames a parameter as every
> parameter would be subject to these rules.
>
> I don't have Wiki karma so can't post th

Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?

[Benjamin Eberlei]

On Wed, Jul 22, 2020 at 2:40 PM Deleu  wrote:

> "Terrible" is the amount of humans having their lives taken by a pandemic.
> This is at most slightly inconvenient for you. The aggressive tone in this
> discussion is extremely unnecessary.
>

After the RFC was voted on for @@, objectively "terrible" (or bad) reasons
for this patch have been found though, that can only be softened by
changing token parsing for namespaces.

This is not a subjective opinion.


> On Wed, Jul 22, 2020 at 2:00 PM Derick Rethans  wrote:
>
> > Hi all,
> >
> > I know we've voted twice on this already, but are we really sure that
> > the @@ syntax is a good idea?
> >
> > - There are lots of grumbles, both on here, room 11, as well as in the
> >   wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/)
> > - It has the distinct possibility to cause further parsing issues, akin
> >   to what ended up happening with what Nikita is addressing at
> >   https://wiki.php.net/rfc/namespaced_names_as_token
> > - There is no "end symbol" to make finding occurences easier.
> > - It is a syntax *no other language* uses.
> > - @ is never going to go away, so the possibility of @@ moving to @ is
> >   also 0.
> >
> > Please, let's do the sensible and use the Rusty #[...] syntax.
> >
> > cheers,
> > Derick
> >
> > --
> > PHP 7.4 Release Manager
> > Host of PHP Internals News: https://phpinternals.news
> > Like Xdebug? Consider supporting me: https://xdebug.org/support
> > https://derickrethans.nl | https://xdebug.org | https://dram.io
> > twitter: @derickr and @xdebug
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>
> --
> Marco Aurélio Deleu
>

Re: [PHP-DEV] 8.0 Feature Freeze in 4 weeks

[Benjamin Eberlei]

On Tue, Jul 21, 2020 at 4:47 PM Sara Golemon  wrote:

> On Tue, Jul 21, 2020 at 9:29 AM Nikita Popov  wrote:
>
> > Just so people aren't surprised, I plan to start landing implementations
> > for RFCs that are likely to be accepted in advance of the actual vote
> > closure, as we have many RFC votes ending close to feature freeze. Of
> > course, if something ends up not passing, it will be reverted.
> >
> > Sounds 100% reasonable, the two you have in voting phase are both looking
> pretty solid.   I'd rather have the hazard of a last-minute revert than a
> last-minute merge.
>

the namespace token one is also a requirement for the attribute syntax @@
patch, which also requires another review cycle afterwards, so this way
it'll be a little less time pressed for that one.

>
> -Sara
>

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

[Benjamin Eberlei]

On Fri, Jul 10, 2020 at 11:21 AM Marco Pivetta  wrote:

> Hi Nikita,
>
> I kept my "NO" stance here, as per discussion in
> https://externals.io/message/110004#110005, where I provided (in my
> opinion) good/safe alternatives to arrays as input parameters.
>

> The BC implications on this RFC still largely outweigh any advantages that
> it brings, from my perspective.
>

Are there alternatives to named parameters? Of course. Are they as simple?
Not really.

1. You can use an array, but array values cannot be typed, so you completly
loose typing of the language.
2. You can use an object with builder pattern, but that requires a lot of
code to write, and increases the mental capacity of understanding something
for developers.
3. your example of an api to convert named params to a sequence is not
discoverable, you don't know looking or using method A() that it comes with
an additional NamedParamsA() helper.

I see PHP as a language to get up and running quickly. So builder pattern
is really more an advanced approach, should be used by not many use-cases.
We have seen
arrays of $options and $params to no end in framework and library APIs,
with all their problems.

So named params are a real improvement that feels like supporting "the php
way(tm)".

Lastly we need to consider internal APIs, which are usually about adding
more parameters (htmlentities, json_decode, ...). These APIs are going to
stay and benefit hugely from named params.

Then the question becomes, do we rename parameters a lot? I doubt it's a
large problem, and even then the variadics support makes it very easy to
handle in a backwards compatible way. In addition libraries are always open
to declare they don't consider named parameters as part of their API.



> Greets,
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Fri, Jul 10, 2020 at 10:42 AM Nikita Popov 
> wrote:
>
> > Hi internals,
> >
> > I have opened voting on the named arguments RFC:
> > https://wiki.php.net/rfc/named_params
> >
> > Voting will close on 2020-07-24.
> >
> > Regards,
> > Nikita
> >
>

Re: [PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void

[Benjamin Eberlei]

On Wed, Jul 8, 2020 at 10:15 PM Benas IML  wrote:

> Hey internals,
>
> I have reopened the voting. It is going to close July 22nd, 2020. I have
> also
> added a "Why allow void return type on constructors/destructors?" section
> which
> I hope internals are going to read and consider before voting. Thanks!
>

I wanted to give a datapoint for my no vote. I think going from forbidding
return types on ctors to requiring them to be void is one step to far. Yes,
the use-cases for returning something from a constructor are questionable,
but why force something that strictly is not something the language should
care about, as it can as easily be a coding style topic.

For me the RFC vote should be "allow to dcelare return types on
constructors/destructors?", then people *can* declare void, but *can* also
declare other things, but nothing *must* be done. Then it becomes a
question of coding styles enforcing "void" for all constructors of a
project for example. I would vote Yes on that.


> RFC:
> https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
> Benas
>
> On Fri, 3 Jul 2020 at 00:12, Benas IML  wrote:
> >
> > Hey internals,
> >
> > I have opened the voting for the RFC, let's hope everything is going
> > to be smooth :). If you have any other questions, let me know!
> >
> > RFC: https://wiki.php.net/rfc/make_ctor_ret_void
> >
> > Best regards,
> > Benas Seliuginas
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][DISCUSSION] Strict operators directive

[Benjamin Eberlei]

On Mon, Jul 6, 2020 at 5:27 PM Arnold Daniels 
wrote:

> Hi all,
>
> I'd like to start the discussion of the "Strict operators directive" RFC
> version 1.5. This RFC proposes a new directive strict_operators, which
> limits the type juggling done by operators to avoid unexpected results.
>
> https://wiki.php.net/rfc/strict_operators
>
> There are some significant changes from the previous version.
> strict_operators no longer has cases where it changes the outcome of an
> operation. To achieve this the following changes are made to the RFC
>
> * All comparison operators, besides `===` and `!==`, only accept `int` and
> `float` operands. For any other type a `TypeError` is thrown. This includes
> `==` and `!=`.
>

what about DateTime and other objects overwriting comparison operators?
(GMP, ...) How would this proposal affect future proposals that expose
comparisons to userland (see for example the operator overloading RFC).

* The `switch` statement is not affected.
>

> For frequently asked questions please see
> https://wiki.php.net/rfc/strict_operators/faq.
>

Honestly PHP comparisons are already complex enough, introducing a second
set of rules that are just as complex seems like a risky proposal to me.

>
> [Arnold Daniels - Chat @ Spike](
> https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=l1bam)
> [l1bam]

Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void

[Benjamin Eberlei]

On Thu, Jul 2, 2020 at 11:12 PM Benas IML  wrote:

> Hey internals,
>
> I have opened the voting for the RFC, let's hope everything is going
> to be smooth :). If you have any other questions, let me know!
>
> RFC: https://wiki.php.net/rfc/make_ctor_ret_void
>
> Best regards,
> Benas Seliuginas
>

Hi Benas,

I wanted to raise what I believe is an issue with the secondary vote going
against PHP policy to introduce a BC break in 8.1, I would imagine policy
overrules voting decision here and it wouldn't matter what people voted
for, it will only be removed at the earliest in 9.0

greetings
Benjamin


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

Re: [PHP-DEV][RFC][VOTE] Rename T_PAAMAYIM_NEKUDOTAYIM to T_DOUBLE_COLON

[Benjamin Eberlei]

On Sat, Jun 27, 2020 at 11:57 AM Andrea Faulds  wrote:

> Hi,
>
> G. P. B. wrote:
> > https://wiki.php.net/rfc/rename-double-colon-token
>
> I have voted No to this, and I hope I can convince some others to do the
> same.
>
> T_PAAMAYIM_NEKUDOTAYIM is such a famous token that there is probably
> nobody in internals who doesn't know what it means, and for new
> contributors, it is easy to find the definition, and note that it is
> hardly the only token name that they will need to look up. It is also a
> fun nod to the history of PHP, and I think it would be a shame to lose
> that.
>
> I mention the internals usage first and foremost, because it should be
> remembered that token names are merely an implementation detail of the
> PHP interpreter, unless you're using token_get_all (which by the way
> already has the alias T_DOUBLE_COLON). In other words, it's not
> something the vast majority of userland developers should ever encounter
> or have to think about.
>
> Of course, if T_PAAMAYIM_NEKUDOTAYIM was never encountered by userland
> developers, this RFC wouldn't exist. The thing is, I don't think
> T_DOUBLE_COLON should be encountered by userland developers either — in
> my view, as an implementation detail, token names shouldn't be part of
> parser error messages at all. If we were to remove token names from the
> parser errors, we would avoid the problem this RFC seeks to solve. For
> most tokens we could simply display the characters it corresponds to
> (e.g. "::" for T_PAAMAYIM_NEKUDOTAYIM, which we already do!), and for
> those with variable content (e.g. T_STRING) we could display a
> human-readable description of what is expected (e.g. "an identifier").
>
> I think the case for not renaming T_PAAMAYIM_NEKUDOTAYIM, and instead
> improving the error messages, is stronger when you consider that is not
> the only token with a name that might confuse people outside internals.
> For example, T_STRING is a very common token, but the name is probably
> going to surprise most userland developers who encounter it in an error
> message, because it doesn't mean a literal string. Even for tokens with
> more conventional names, it is unnecessary extra information. I think
> renaming just T_PAAMAYIM_NEKUDOTAYIM is not a full solution to the
> problem this RFC intends to solve.
>
> Apropos of that:
>
>  > We did acknowledge the suggestion of dropping the token name from the
>  > error message directly, but in our opinion this is an orthogonal
>  > change to the one proposed, and has the risk of not landing in PHP
>  > 8.0.
>
> Is PHP 8.0 an all-important? If we _don't_ rename the tokens, but simply
> improve the error message, that might be allowable in a patch release
> (e.g. 8.0.1).
>
> (I also don't think we should rush things if we are unsure about them,
> given the consequences that has had in the past.)
>

This is the same reason that I voted no.

1. The token name has historic value and should be preserved as such
2. as several people suggested in the original RFC discussion, we should
just not display tokens in error messages anymore. That should have been
the RFCs solution, not renaming the token

>
> Thanks,
> Andrea
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: [VOTE] Attribute Amendments

[Benjamin Eberlei]

On Mon, Jun 22, 2020 at 6:57 PM David Rodrigues 
wrote:

> I like to suggest that, by default, attributes could be repeatable, so we
> can disable this instead (eg. "@@ Attribute(self::IS_UNIQUE)").
>
>
during research we found that most of the attributes really have to be
unique, and only a small number is usually repeatable. So making them
unique by default and only repeatable on request is the better approach.

>
> Atenciosamente,
> David Rodrigues
>
>
> Em seg., 22 de jun. de 2020 às 13:38, Benjamin Eberlei <
> kont...@beberlei.de> escreveu:
>
>> Hello,
>>
>> The voting period is over and all four votes have been accepted:
>>
>> - Rename PhpAttribute to Attribute
>> - Allow grouped syntax (though this will probably be obsolete looking at
>> @@
>> syntax currently winning the re-vote)
>> - Attribute targets
>> - Attribute repeatability
>>
>> Thank you everyone!
>>
>> On Mon, Jun 8, 2020 at 10:12 AM Benjamin Eberlei 
>> wrote:
>>
>> > Hello internals,
>> >
>> > I have opened voting for four different amendments to the Attributes RFC
>> >
>> > https://wiki.php.net/rfc/attribute_amendments
>> >
>> > The voting period ends at 2020-06-22 8:00 UTC.
>> >
>> > greetings
>> > Benjamin
>> >
>>
>

[PHP-DEV] Re: [VOTE] Attribute Amendments

[Benjamin Eberlei]

Hello,

The voting period is over and all four votes have been accepted:

- Rename PhpAttribute to Attribute
- Allow grouped syntax (though this will probably be obsolete looking at @@
syntax currently winning the re-vote)
- Attribute targets
- Attribute repeatability

Thank you everyone!

On Mon, Jun 8, 2020 at 10:12 AM Benjamin Eberlei 
wrote:

> Hello internals,
>
> I have opened voting for four different amendments to the Attributes RFC
>
> https://wiki.php.net/rfc/attribute_amendments
>
> The voting period ends at 2020-06-22 8:00 UTC.
>
> greetings
> Benjamin
>

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Benjamin Eberlei]

On Thu, Jun 18, 2020 at 1:59 AM Theodore Brown 
wrote:

> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax
>
> Since all RFCs require a primary vote with a 2/3 majority, there is
> a main vote to approve the secondary ranked-choice vote.
>
> For the ranked-choice poll, fill in your first through third syntax
> choices, making sure not to select the same syntax more than
> once. You don't have to vote for all three options, but please
> don't leave gaps.
>
> Voting will end in two weeks, on 2020-07-01.
>

Thank you for working on this RFC. The syntax question for Attributes is a
really hot topic and I think it is a good idea to have a re-vote with more
varied options than before.

The two new options now proposed didn't even cross my and Martin's mind for
the original RFC, because we strictly looked at syntaxes with no BC breaks.
Both @@ and #[] introduce very small, but also easily detectable and
fixable (via grep + sed or tools of choice).

>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Benjamin Eberlei]

On Tue, Jun 9, 2020 at 2:07 PM Lynn  wrote:

>
>
> On Tue, Jun 9, 2020 at 1:55 PM Benjamin Eberlei 
> wrote:
>
>> Larry's suggestion about #[Attr] makes an important argument about
>> allowing
>> to declare attributes in code in PHP 7 in a forward compatible way that
>> has
>> not been brought up before.
>>
>> /** @ORM\Entity */
>> #[ORM\Entity]
>> class User {}
>>
>> This code would work on PHP 7 and 8.
>>
>> The #[] syntax would have about equally low breaking potential as @@. It
>> would be the same syntax as Rusts, and close to C++/C# syntax.
>>
>
> Hi,
>
> The idea of making annotations forward compatible in php7 this way has a
> big + from me. I honestly don't mind the syntax too much. How would
> multiline notations work with this?
>
> #[ORM\Entity(
> arg1,
> arg2
> )]
>
> This notation would obviously break in php7. Would it be possible (in this
> case) to do something like the following example? This would have php7 not
> care because they are comments, while php8 could filter the # out and make
> it a valid annotation.
>

Good point. The forward compatible syntax would need to require single line
declarations as you suggested, because the multiline syntax as you rightly
show is not valid php7.

The alternative would be requiring each attribute line to begin with #,
which I don't particularly care for and would probably be a mistake.


> #[ORM\Entity(
> #   arg1,
> #   arg2
> #)]
>
> I'm also okay with having everything on a single line, just wanted to
> point out this might cause issues.
>
> Regards,
> Lynn
>
>

Re: [PHP-DEV] [RFC] Shorter attribute syntax

[Benjamin Eberlei]

On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown 
wrote:

> Hi internals,
>
> I discussed the syntax for attributes further with Benjamin, Martin,
> and several other internals developers off-list, and with their
> feedback completed an RFC proposing to use the shorter `@@` syntax
> instead of `<<>>` for attributes in PHP 8.
>
> https://wiki.php.net/rfc/shorter_attribute_syntax
>
> The goal is not to bikeshed over subjective syntax preferences,
> but to address several concrete shortcomings related to verbosity,
> nested attributes, confusion with generics and other tokens, and
> dissimilarity to other common languages.
>

Larry's suggestion about #[Attr] makes an important argument about allowing
to declare attributes in code in PHP 7 in a forward compatible way that has
not been brought up before.

/** @ORM\Entity */
#[ORM\Entity]
class User {}

This code would work on PHP 7 and 8.

The #[] syntax would have about equally low breaking potential as @@. It
would be the same syntax as Rusts, and close to C++/C# syntax.

As such, instead of going through each alternative syntax one by one, with
with each having a 2/3 requirement to overthrow the old one,
I would be open to restart the secondary vote on Attributes syntax with
<<>> (status quo), @@ and #[] using the same ranked voting algorithm that
was used for the PHP 8 RM vote.

@Sara @Gabriel I suppose this is something you two should be ok with (and
Theodore of course).

I would take on the work to write about the third syntax alternative then.
The VoteRFC could just link to the three individual RFCs where each
discusses their syntax.


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