Re: [PHP-DEV] [RFC] Amendments to Attributes
> Am 22.05.2020 um 13:08 schrieb Nikita Popov :
>
> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei
> wrote:
>
>> 2. Rename PhpAttribute to Attribute in global namespace (independent of the
>> namespace RFC)
>
> As was mentioned in one of the previous discussions, we expect that PHP is
> going to ship more language-provided attributes in the future. With this
> proposal we have the "Attribute" attribute, but I expect we'll at least
> have "Deprecated" as well, and probably also something along the lines of
> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global
> namespace, I don't really think we'd want to introduce "Jit" as a class in
> the global namespace. The name is simply to generic and does not indicate
> that this is part of the attribute system. We'd be forced to go with things
> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to
> me, as we're just reinventing namespaces to avoid using them...
>
> As such, I would suggest to introduce a common namespace for all attributes
> provided by PHP. This means we'd have Attributes\Attribute,
> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay
> with the PHP\Attributes\Deprecated variant, but that's a separate question).
>
> Nikita
At that point, don't we just want to be able to generically mark all attribute
classes visible as being an Attribute?
Also the classical examples like <> do not tell you anyhow
that they're Attributes, if the class is accessed outside of attribute context.
And I guess, with the logic you proposed, it will likely be named
"ORM\Attribute\Entity" making it even longer.
I think it would be good to be able to later on just write <>,
<> etc. without further imports, as they seem to be quite basic
functionality. I think it should remain possible to write simple code without
much namespace awareness.
Perhaps we should actually name attribute classes including their << and >>.
Thus "class <> {}" (attribute decl), "new <>()" (custom
instantiation), "$attribute instanceof <>". (and, for a namespaced
attribute "$attribute instanceof MyNamespace\<>")
The engine could quite easily support that, it's just a little parser work.
That way the whole discussion as to where to put attributes in the namespace
hierarchy would be quite moot, for PHP itself as well as userland.
Bob
P.s.: As a caveat, on parameter types, if we expect a value being of an
attribute class, we'd need to require a qualified name containing at least one
backslash or import-alias there. But that's acceptable I think, it will just
happen within some internal attribute processing code.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Amendments to Attributes
On Fri, May 22, 2020 at 5:28 PM Nikita Popov wrote: > > I don't particularly care what namespace the attribute classes are under, > just that they should have a common namespace, because there's going to be > many of them, presumably. If it was just a matter of the Attribute class, > I'd definitely say this belongs in the global namespace, but that's not > what we're dealing with at this point. > You've made a really good argument for the \Php namespace here. I get that PHP reserves the global namespace, but I'm pretty certain that if PHP ever needs any subspaces, they should be under a common, non-global, namespace. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
On Fri, May 22, 2020, at 10:42 AM, Ilija Tovilo wrote: > Hi Larry > > > My one question is why you're not including the implicit "match (true)" > > in this version, when the secondary vote on the previous RFC was > > 80% in favor of it. > > I received quite a bit of feedback that the RFC was too complex. I > tried to make the RFC simpler by removing all non-essential parts. I'm > ready to create a follow up RFC for this (although it would probably > not make PHP 8.0). Hm. A logical argument, but given its overwhelming support before and that it's therefore almost certain to pass in the future, I don't see why it's a net win to have PHP 8.0 missing that bit. It seemed uncontroversial, and seems like a highly common use case. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods
Hey Bruce, On Fri, May 22, 2020, 22:07 Bruce Weirdan wrote: > > On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote: > >> Overall, this RFC breaks some design capabilities that are within the >> language, specifically around `__`-prefixed methods in the language. > > > Wouldn't your use cases be covered by `protected final` though, as > proposed by Pedro? > This design is made appositely to prevent the child class from being able to call the constructor: the only viable constructors are the named constructors on the supertype >
Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods
On Fri, May 22, 2020 at 7:26 PM Marco Pivetta wrote: > Overall, this RFC breaks some design capabilities that are within the > language, specifically around `__`-prefixed methods in the language. Wouldn't your use cases be covered by `protected final` though, as proposed by Pedro? -- Best regards, Bruce Weirdan mailto: weir...@gmail.com
Re: [PHP-DEV] Re: [RFC][VOTE] PHP Namespace in core
On 22/05/2020 19:32, Rowan Tommins wrote: * They might even prefer your RFC, which is still marked "Under Discussion": https://wiki.php.net/rfc/php_namespace_policy Even though the two RFCs were seperate and created without each others knowledge, I don't know how people would feel about holding a similar one if this one was voted down. If this one passed it was my intention to immediately vote on my own, which would change the policy to require sub-namespaces and limit it to autoloadable components. Which wouldn't make sense if \PHP was still denied. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][VOTE] PHP Namespace in core
On 22/05/2020 18:30, Mark Randall wrote: Should this vote fail, \PHP effectively changes from a reserved namespace, to a dead namespace. I don't see how you get from the text of this RFC to that conclusion. There are a number of reasons why people who vote against this RFC might vote for an alternative, such as: * They would prefer *more* classes to be in \PHP * They would prefer fewer classes, but not none * They would prefer a similar number of classes, but a different definition * They would prefer a guideline with "should" or "may" rather than "must" * They like the definition, but would prefer a plan to rename existing classes that meet it, for consistency (I don't have a vote, but I might well vote No on this basis) * They would prefer a concrete proposal on how to structure the namespace, which this RFC explicitly is not * They might even prefer your RFC, which is still marked "Under Discussion": https://wiki.php.net/rfc/php_namespace_policy It is possible that "officially declare that we won't use the \PHP namespace" would get a majority, but that's not what this vote asks. Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][VOTE] PHP Namespace in core
On 22/05/2020 07:14, Michał Brzuchalski wrote: Hi Internals, We have just opened the vote on the PHP namespace in core RFC. The voting will be open for two weeks, until 2020-06-05 06:00 UTC. Link: https://wiki.php.net/rfc/php-namespace-in-core#vote Cheers, Michał Marcin Brzuchalski I hope that those voting look to the long term, the next 10 to 20 years, and the potentially hundreds of new classes that they may bring. I hope those voting don't choose to place a senseless blanket limitation on the options available to all future RFC authors, even before those authors have had an opportunity to make their case for their individual usage of \PHP. Should this vote fail, \PHP effectively changes from a reserved namespace, to a dead namespace. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode
On Fri, 22 May 2020 at 18:09, Katie Volz wrote: > Hello internals, > > I want to start a discussion on an RFC to add a declare() statement to > convert all errors triggered within a file to exceptions. > > Currently, the only way to handle notices/warnings in an exception-like > manner is via set_error_handler, (for example, example #1 on > https://www.php.net/errorexception) - however this has several > disadvantages (in particular, it cannot be safely used in libraries without > affecting other libraries). The declare() would only affect code on the > particular PHP file for which the declare was set to 1, in the same way > that strict_types only affects code on a particular PHP file. I have > listed error_exception, error_exceptions, and strict_errors as potential > names for the declare(), although I don't feel that any of them clearly and > succinctly describe what is happening here (if anyone has a better name I'm > certainly interested). > > As I do not have wiki karma, I have posted a draft RFC here: > https://github.com/iggyvolz/php-rfcs/blob/master/error-exceptions.txt. A > partially complete patch is linked at the bottom of the draft (very much > based off the strict_types patch). > > Thanks, > Katie Volz > I did a similar PoC last summer (see: https://github.com/php/php-src/pull/4549) where Nikita commented that a lot of those warnings could/should be promoted to error regardless, and this is what myself and a couple of other people have been during for the past year. There are still extensions which didn't receive this treatment mostly due to lack of time and hands, so if you want to join on this feel free to send a PR to php-src Due to the work already done, I personally see less interest in such a declare. Mostly because doing a promotion of these warnings, which are usually tied in to a failure return value such as null or false, allows us in some instance to "clean" up the return value, but only if it's done on the extension level/in core. Now I do acknowledge the number of E_WARNINGs still present on master is large, but I'd personally prefer to focus on making the language better for everyone and let legit warnings be warnings mostly due to the legacy behaviour for I/O operations. Best regards George P. Banyard
Re: [PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode
On 22/05/2020 17:08, Katie Volz wrote:
I want to start a discussion on an RFC to add a declare() statement to
convert all errors triggered within a file to exceptions.
Hi Katie,
Personally, I'm not a fan of promoting messages to exceptions in this
way, because APIs designed to throw exceptions generally look rather
different from ones designed to warn and continue, so blindly converting
seems like putting a square peg in a round hole. However, I know people
do it already, so will give my thoughts on the principle.
My main concern is that it needs a tighter definition of "error", and
possibly a configurable one.
The snippet from the manual which you include in your draft RFC
references the current global error_reporting setting. This makes sense
with a global error handler, but less so for a per-file declare - it
means the caller can choose whether exceptions are thrown, somewhat
defeating the point. Perhaps the declare directive could take an error
level as its argument, e.g. declare(error_exceptions=E_ALL-E_NOTICE)?
Relatedly, you would need to define how this interacts with the @ (error
suppression or "shut up") operator - would that force the code to run
past a point that would otherwise throw an exception? Again, I think
that choice should be taken away from the caller, otherwise the author
needs to account for both modes, e.g.
declare(error_exceptions=E_WARNING);
try {
$fh = fopen($blah, $mode);
// if caller can suppress ErrorExceptions, we still need to check
if $fh is false
// ...
} catch ( ErrorException $e ) {
// the caller shouldn't actually care what happens, because we can
catch it here
}
Other than that, there's the usual awkwardness of declare - it has to be
set in each file, and new directives are errors in old versions of PHP.
That doesn't necessarily mean we shouldn't use it for now, though.
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods
Hey Pedro,
On Fri, May 22, 2020 at 5:43 PM Pedro Magalhães wrote:
> Hi internals,
>
> I want to put up for discussion an RFC (
> https://wiki.php.net/rfc/inheritance_private_methods) that proposes to
> remove some inappropriate signature checks that are still done on private
> methods. Namely, those checks are:
>
> - When a method has the same name as a parent's final private method
> - When a method has the same name as a parent's static private method and
> the child's method is non-static, or vice-versa
> - When a method has the same name as a parent's concrete private method and
> the child's method is abstract
>
> I have 2 open issues on the RFC that I would like to hear some opinions on.
> - Whether or not to issue a compiler warning whenever "final private
> function" is used, to alert the user that it will not achieve what that
> construct is currently used for. The disadvantage of introducing it is the
> BC break.
> - Whether or not to make an exception to this rule for magic methods. Given
> that this is widely to restrict object instantiation and cloning, it could
> make sense to still allow the use on those cases. However, I think that the
> similar effect that can be achieved with "final protected function" would
> cover most of the cases. And if we open up that exception for magic
> methods, for the sake of clarity maybe we should just keep the "final
> private" behavior on all methods and just change the static and the
> abstract behaviors. Some discussion on this subject can be found on the PR
> (
> https://github.com/php/php-src/pull/5401) for this RFC.
>
Overall, this RFC breaks some design capabilities that are within the
language, specifically around `__`-prefixed methods in the language.
For instance, I design (on purpose) sealed types as following:
```php
abstract class Email
{
final private function __construct() {}
public static function business(): Business {
return new Business();
}
public static function personal(): Personal {
return new Personal();
}
}
final class Business extends Email {}
final class Personal extends Email {}
```
The above approach guarantees that no further subtypes exist for `Email`,
other than `Business` or `Personal`, effectively forming a safe union type,
which can only be broken by reflection.
In addition to that, I often prevent serialization of types that are not
intended to be serialized (when not final):
```php
abstract class InMemorySecret
{
final private function __sleep() {}
}
```
Effectively, the `final` modifier applies to `private` symbols too, and
prevents child classes from deviating from imposed design constraints.
It is **intentional** for `private` symbol overrides to not compile in
these cases.
Both of the above examples only apply to special/magic methods: I can see
and understand that for custom methods this RFC may be valid, and adding a
further refinement to lift the restriction only on custom methods is a good
idea.
Marco Pivetta
http://twitter.com/Ocramius
http://ocramius.github.com/
[PHP-DEV] [RFC][DISCUSSION] Error Exceptions mode
Hello internals, I want to start a discussion on an RFC to add a declare() statement to convert all errors triggered within a file to exceptions. Currently, the only way to handle notices/warnings in an exception-like manner is via set_error_handler, (for example, example #1 on https://www.php.net/errorexception) - however this has several disadvantages (in particular, it cannot be safely used in libraries without affecting other libraries). The declare() would only affect code on the particular PHP file for which the declare was set to 1, in the same way that strict_types only affects code on a particular PHP file. I have listed error_exception, error_exceptions, and strict_errors as potential names for the declare(), although I don't feel that any of them clearly and succinctly describe what is happening here (if anyone has a better name I'm certainly interested). As I do not have wiki karma, I have posted a draft RFC here: https://github.com/iggyvolz/php-rfcs/blob/master/error-exceptions.txt. A partially complete patch is linked at the bottom of the draft (very much based off the strict_types patch). Thanks, Katie Volz
Re: [PHP-DEV] [RFC] Amendments to Attributes
On Fri, May 22, 2020 at 5:29 PM Benjamin Eberlei wrote: > > > On Fri, May 22, 2020 at 1:08 PM Nikita Popov wrote: > >> On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei >> wrote: >> >>> Hi everyone, >>> >>> the Attributes RFC was rather large already, so a few things were left >>> open >>> or discussions during the vote have made us rethink a things. >>> >>> https://wiki.php.net/rfc/attribute_amendments >>> >>> These points are handled by the Amendments RFC to Attributes: >>> >>> 1. Proposing to add a grouped syntax < >> >> 2. Rename PhpAttribute to Attribute in global namespace (independent of >>> the >>> namespace RFC) >>> >> >> As was mentioned in one of the previous discussions, we expect that PHP >> is going to ship more language-provided attributes in the future. With this >> proposal we have the "Attribute" attribute, but I expect we'll at least >> have "Deprecated" as well, and probably also something along the lines of >> "Jit" or "NoJit". While I'm happy with "Attribute" living in the global >> namespace, I don't really think we'd want to introduce "Jit" as a class in >> the global namespace. The name is simply to generic and does not indicate >> that this is part of the attribute system. We'd be forced to go with things >> like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to >> me, as we're just reinventing namespaces to avoid using them... >> >> As such, I would suggest to introduce a common namespace for all >> attributes provided by PHP. This means we'd have Attributes\Attribute, >> Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay >> with the PHP\Attributes\Deprecated variant, but that's a separate question). >> > > Deprecated would be an "engine level" feature, but Opcache is an > extension, so it can have its own namespace "Opcache\Jit". The namespace > RFC goes that far mentioning only " core symbols which cannot be unbundled" > should go into a PHP namespace, which would exclude Opcache (and its > "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core > > So for me that is not necessarily an argument against Attribute in global > NS, because Jit would live in Opcache\. > Interesting point. I think this is more an argument against using a "PHP" vendor namespace, than against using an "Attributes" namespace. JIT is not "really" an opcache feature, it just lives in opcache right now because it happens to be convenient. There are long term plans to move the optimization-related functionality from opcode into core, and JIT should also live in core (and I think there are plenty of workloads that are interested in JIT without the SHM caching). Given that context, calling the attribute Opcache\Jit seems somewhat ill-advised. I also think we'd want to provide this attribute independently of whether opcache is actually loaded, because annotating functions with it would be rather problematic if it's not always available... Ultimately I'm okay with going with just "Attribute" here, but we need to acknowledge that this comes with future obligations. In particular, introducing a "Deprecated" class is a "no" from me, because the name is too generic and does not indicate that this is part of the attribute system. It will need to be "DeprecatedAttribute" (or "Attribute_Deprecated", ugh). Which also means that you need to "use DeprecatedAttribute as Deprecated" to use it. This isn't terrible, but I also don't think it's ideal. Regards, Nikita
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
Hey Ilija, On Fri, May 22, 2020 at 1:08 PM Ilija Tovilo wrote: > Hi internals > > I'd like to announce the match expression v2 RFC: > https://wiki.php.net/rfc/match_expression_v2 > [...] > Given that many people have said without blocks they'd vote yes I'd > say this is the case here. Let me know if you don't agree. > > This looks exactly like the construct that I'd vote for: good work! :-) Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
[PHP-DEV] [RFC] [Discussion] Remove inappropriate inheritance signature checks on private methods
Hi internals, I want to put up for discussion an RFC ( https://wiki.php.net/rfc/inheritance_private_methods) that proposes to remove some inappropriate signature checks that are still done on private methods. Namely, those checks are: - When a method has the same name as a parent's final private method - When a method has the same name as a parent's static private method and the child's method is non-static, or vice-versa - When a method has the same name as a parent's concrete private method and the child's method is abstract I have 2 open issues on the RFC that I would like to hear some opinions on. - Whether or not to issue a compiler warning whenever "final private function" is used, to alert the user that it will not achieve what that construct is currently used for. The disadvantage of introducing it is the BC break. - Whether or not to make an exception to this rule for magic methods. Given that this is widely to restrict object instantiation and cloning, it could make sense to still allow the use on those cases. However, I think that the similar effect that can be achieved with "final protected function" would cover most of the cases. And if we open up that exception for magic methods, for the sake of clarity maybe we should just keep the "final private" behavior on all methods and just change the static and the abstract behaviors. Some discussion on this subject can be found on the PR ( https://github.com/php/php-src/pull/5401) for this RFC. Regards, Pedro Magalhães
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
Hi Larry > My one question is why you're not including the implicit "match (true)" > in this version, when the secondary vote on the previous RFC was > 80% in favor of it. I received quite a bit of feedback that the RFC was too complex. I tried to make the RFC simpler by removing all non-essential parts. I'm ready to create a follow up RFC for this (although it would probably not make PHP 8.0). > (And I still think the argument is stronger if you include a comparison > to ternary assignment, but that doesn't affect implementation.) Makes sense, I will incorporate an example :) Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Match expression v2
On Fri, May 22, 2020, at 6:08 AM, Ilija Tovilo wrote: > Hi internals > > I'd like to announce the match expression v2 RFC: > https://wiki.php.net/rfc/match_expression_v2 > > The goal of the new draft is to be as simple and uncontroversial as > possible. It differs from v1 in the following ways: > > * Blocks were removed > * Secondary votes were removed > * optional semicolon > * omitting `(true)` > * Unimportant details were removed (e.g. examples for future scope) > > You can look at the diff here: > https://github.com/iluuu1994/match-expression-rfc/pull/8/files > > I will also leave the discussion period open for longer as that too > was one of the primary criticisms. > > As mentioned by Kalle: > > > Resurrecting rejected RFCs have a "cooldown" of 6 months: > > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals > > That is, unless: > > > The author(s) make substantial changes to the proposal. While it's > > impossible to put clear definitions on what constitutes 'substantial' > > changes, they should be material enough so that they'll significantly > > affect the outcome of another vote. > > Given that many people have said without blocks they'd vote yes I'd > say this is the case here. Let me know if you don't agree. > > Ilija I'd say this is a textbook example of sufficiently "substantial." Thanks, Ilija! This looks a lot better. My one question is why you're not including the implicit "match (true)" in this version, when the secondary vote on the previous RFC was 80% in favor of it. (And I still think the argument is stronger if you include a comparison to ternary assignment, but that doesn't affect implementation.) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Amendments to Attributes
On Fri, May 22, 2020 at 1:08 PM Nikita Popov wrote: > On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei > wrote: > >> Hi everyone, >> >> the Attributes RFC was rather large already, so a few things were left >> open >> or discussions during the vote have made us rethink a things. >> >> https://wiki.php.net/rfc/attribute_amendments >> >> These points are handled by the Amendments RFC to Attributes: >> >> 1. Proposing to add a grouped syntax < > > 2. Rename PhpAttribute to Attribute in global namespace (independent of the >> namespace RFC) >> > > As was mentioned in one of the previous discussions, we expect that PHP is > going to ship more language-provided attributes in the future. With this > proposal we have the "Attribute" attribute, but I expect we'll at least > have "Deprecated" as well, and probably also something along the lines of > "Jit" or "NoJit". While I'm happy with "Attribute" living in the global > namespace, I don't really think we'd want to introduce "Jit" as a class in > the global namespace. The name is simply to generic and does not indicate > that this is part of the attribute system. We'd be forced to go with things > like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to > me, as we're just reinventing namespaces to avoid using them... > > As such, I would suggest to introduce a common namespace for all > attributes provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate question). > Deprecated would be an "engine level" feature, but Opcache is an extension, so it can have its own namespace "Opcache\Jit". The namespace RFC goes that far mentioning only " core symbols which cannot be unbundled" should go into a PHP namespace, which would exclude Opcache (and its "sub-extension" JIT). https://wiki.php.net/rfc/php-namespace-in-core So for me that is not necessarily an argument against Attribute in global NS, because Jit would live in Opcache\. > > Nikita > > 3. Add validation of attribute class targets, which internal attributes can >> do, but userland can't >> 4. Specification if an attribute is repeatable or not on the same >> declaration and fail otherwise. >> >> Each of them is a rather small issue, so I hope its ok to aggregate all >> four of them in a single RFC. Please let me know if it's not. >> >> greetings >> Benjamin >> >
Re: [PHP-DEV] [RFC] Amendments to Attributes
On Fri, May 22, 2020 at 2:19 PM Benas IML wrote: > Agreed. > > I don't think we should pollute any other than the `PHP\` namespace. If > that RFC doesn't pass though, we should keep the `Attribute` class in the > global namespace. > > Global namespace is already reserved for PHP and so, BC breaks aren't that > severe whereas `Attributes\` namespace isn't reserved therefore BC breaks > would be "unexpected". > > Best regards, > Benas Seliuginas > I mean, realistically speaking, BC breaks with Attributes\Attribute are a lot less likely than with just Attribute, regardless of what we reserve or don't. Some pragmatism, please. I don't particularly care what namespace the attribute classes are under, just that they should have a common namespace, because there's going to be many of them, presumably. If it was just a matter of the Attribute class, I'd definitely say this belongs in the global namespace, but that's not what we're dealing with at this point. Nikita
Re: [PHP-DEV] [RFC] Amendments to Attributes
Agreed. I don't think we should pollute any other than the `PHP\` namespace. If that RFC doesn't pass though, we should keep the `Attribute` class in the global namespace. Global namespace is already reserved for PHP and so, BC breaks aren't that severe whereas `Attributes\` namespace isn't reserved therefore BC breaks would be "unexpected". Best regards, Benas Seliuginas
Re: [PHP-DEV] [RFC] Amendments to Attributes
On Fri, 22 May 2020 at 12:09, Nikita Popov wrote: > While I'm happy with "Attribute" living in the global > namespace, I don't really think we'd want to introduce "Jit" as a class in > the global namespace. The name is simply to generic and does not indicate > that this is part of the attribute system. We'd be forced to go with things > like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to > me, as we're just reinventing namespaces to avoid using them... > > As such, I would suggest to introduce a common namespace for all attributes > provided by PHP. This means we'd have Attributes\Attribute, > Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay > with the PHP\Attributes\Deprecated variant, but that's a separate > question). > This is the best real-world argument in favour of PHP namespace in core that I've heard. https://wiki.php.net/rfc/php-namespace-in-core If we don't want to introduce classes in the global namespace, it makes sense to have a reserved PHP namespace we use. Peter
[PHP-DEV] [RFC][DISCUSSION] Match expression v2
Hi internals I'd like to announce the match expression v2 RFC: https://wiki.php.net/rfc/match_expression_v2 The goal of the new draft is to be as simple and uncontroversial as possible. It differs from v1 in the following ways: * Blocks were removed * Secondary votes were removed * optional semicolon * omitting `(true)` * Unimportant details were removed (e.g. examples for future scope) You can look at the diff here: https://github.com/iluuu1994/match-expression-rfc/pull/8/files I will also leave the discussion period open for longer as that too was one of the primary criticisms. As mentioned by Kalle: > Resurrecting rejected RFCs have a "cooldown" of 6 months: > https://wiki.php.net/rfc/voting#resurrecting_rejected_proposals That is, unless: > The author(s) make substantial changes to the proposal. While it's > impossible to put clear definitions on what constitutes 'substantial' > changes, they should be material enough so that they'll significantly > affect the outcome of another vote. Given that many people have said without blocks they'd vote yes I'd say this is the case here. Let me know if you don't agree. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Amendments to Attributes
On Wed, May 20, 2020 at 7:08 PM Benjamin Eberlei wrote: > Hi everyone, > > the Attributes RFC was rather large already, so a few things were left open > or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) > As was mentioned in one of the previous discussions, we expect that PHP is going to ship more language-provided attributes in the future. With this proposal we have the "Attribute" attribute, but I expect we'll at least have "Deprecated" as well, and probably also something along the lines of "Jit" or "NoJit". While I'm happy with "Attribute" living in the global namespace, I don't really think we'd want to introduce "Jit" as a class in the global namespace. The name is simply to generic and does not indicate that this is part of the attribute system. We'd be forced to go with things like DeprecatedAttribute or JitAttribute, which seems rather non-optimal to me, as we're just reinventing namespaces to avoid using them... As such, I would suggest to introduce a common namespace for all attributes provided by PHP. This means we'd have Attributes\Attribute, Attributes\Deprecated, Attributes\Jit, Attributes\NoJit etc. (I'm also okay with the PHP\Attributes\Deprecated variant, but that's a separate question). Nikita 3. Add validation of attribute class targets, which internal attributes can > do, but userland can't > 4. Specification if an attribute is repeatable or not on the same > declaration and fail otherwise. > > Each of them is a rather small issue, so I hope its ok to aggregate all > four of them in a single RFC. Please let me know if it's not. > > greetings > Benjamin >
Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0
On Thu, May 21, 2020 at 11:54 PM Rowan Tommins wrote: > Hi all, > > A few years ago, I posted a message suggesting that PHP improve support > for HTTP/1.1 in its stream wrapper functions: > https://externals.io/message/96192 > > A quick summary of the current situation: > > * HTTP/1.1 was officially standardised in January 1997, and most web > browsers had already implemented it by then > * PHP has a very simple HTTP client implementation, used by the "http:" > and "https:" stream wrappers, and also by extensions which make HTTP > requests, such as ext/soap > * The client implementation defaults to advertising HTTP/1.0 requests, > unless over-ridden by a stream context option > * Since a lot of servers only actually talk HTTP/1.1, the client mostly > acts as an HTTP/1.1 client even when advertising HTTP/1.0 > > > In my previous message, I identified four requirements in HTTP/1.1 but > not HTTP/1.0 that are relevant to a client: > > a) Send a "Host" header with every request. (RFC 7230 Section 5.4) > b) Support persistent connections, or send "Connection: Close" with each > request. (RFC 7230 Section 6.1) > c) Ignore 1xx status lines (notably, "100 Continue") "even if the client > does not expect one" (RFC 7231 Section 6.2) > d) Support "chunked" transfer encoding (RFC 7230 Section 4.1) > > > The PHP client now supports all four regardless of protocol version > configured, i.e. it always sends "Host:" and "Connection: Close" > headers; and always handles "100 Continue" and "Transfer-Encoding: > Chunked" if returned by the server. > > I would like to propose that the client advertises HTTP/1.1 in its > requests by default in PHP 8.0. Users can opt out of this behaviour in > a fully backwards- and forwards-compatible way if necessary using a > stream context option, e.g.: > https://gist.github.com/IMSoP/a685fed6589435530102d57138755511 > > > What are people's opinions? Does this need an RFC, or should I just > submit a PR if nobody objects? > Sounds good to me. Assuming there are no objections, feel free to just send a PR. @Eliot: Unfortunately we don't implement HTTP 2 in the http:// stream wrapper, so HTTP 1.1 is the best we can do there right now. We only provide HTTP 2 support through the curl extension. Implementing HTTP 2 support would certainly be a possibility, but I don't think it's particularly easy to do so without pulling in a dependency like nghttp2. @Max: I'm only guessing here, because I'm not familiar with the historical context, but I imagine part of the motivation is to support HTTP requests in a minimal build of PHP, which does not have any dependencies (that we do not bundle ourselves). We did actually provide an implementation of the http:// stream wrapper via curl for a long time, but dropped it at some point, because there were many subtle behavior differences to our native implementation. Regards, Nikita
Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0
On Fri, May 22, 2020 at 12:54 AM Rowan Tommins wrote: > * PHP has a very simple HTTP client implementation, used by the "http:" > and "https:" stream wrappers, and also by extensions which make HTTP > requests, such as ext/soap Sorry, I'm an internals noob, but why does PHP implement this at all, instead of using an external library like cURL which is already fairly prominent in our ecosystem? -- Best regards, Max Semenik
Re: [PHP-DEV] HTTP/1.1 by default in PHP 8.0
[2nd try, this time with proper etiquette] Hi Rowan and Larry and others, On 21.05.20 23:53, Rowan Tommins wrote: > > I would like to propose that the client advertises HTTP/1.1 in its > requests by default in PHP 8.0. Users can opt out of this behaviour > in a fully backwards- and forwards-compatible way if necessary using a > stream context option, e.g.: > https://gist.github.com/IMSoP/a685fed6589435530102d57138755511 > > > What are people's opinions? Does this need an RFC, or should I just > submit a PR if nobody objects? > To me the only question is whether you want HTTP1.1 or 2 to be the default. version 2 is a bit more complex, to be sure, but quite powerful in avoiding blocking. Eliot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC][VOTE] PHP Namespace in core
Hi Internals, We have just opened the vote on the PHP namespace in core RFC. The voting will be open for two weeks, until 2020-06-05 06:00 UTC. Link: https://wiki.php.net/rfc/php-namespace-in-core#vote Cheers, Michał Marcin Brzuchalski
