Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
I have been wondering for a while why PHP does not officially recognize a \PHP namespace. The inconsistency people have mentioned feels like a fair tradeoff for allowing new core classes to be cleanly-named and easier to understand. And a \PHP namespace would allow RFCs to never need worry about conflicting with userland class names again. The one thing I would ask the authors: - Why limit it to "tightly coupled to the PHP engine?" - Why not just say "any new core classes that are approved to use it?" After all, sometimes a namespace is just a namespace. Seems like a winner to me. -Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function pipe operator
Hi! > https://wiki.php.net/rfc/pipe-operator-v2 Just a small pedantry note - in a comparison section, the RFC compares this syntax to function composition. But this is not function composition. This is a syntax sugar for calling two functions one after another, not operator that produces a function. It sounds pedantic but it's rather important distinction - if |> is composition, than $foo |> $bar is a new callable provided $foo and $bar are callable (but no function is actually being called here!). If |> is call syntax, it's actually the result of calling $bar($foo). So comparing it to function composition is a bit confusing. Otherwise it looks OK to me, except the syntax for calling functions and methods is a bit awkward, but it's not the problem of this RFC I imagine. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function pipe operator
On Mon, Apr 20, 2020 at 9:39 PM Ben Ramsey wrote: > > On Apr 20, 2020, at 20:38, Larry Garfield > wrote: > > > > I've been commenting on other RFCs enough lately that I should probably > put myself through the wringer, too. I therefore offer this RFC to add a > function pipe operator, as seen in a number of other languages: > > > > https://wiki.php.net/rfc/pipe-operator-v2 > > > Happy with the revival, and I do want to underline the "Future Work" section about Partial Functions. PF will make this version of pipes 100% more readable and fluent, and I want to endorse both, but I'll take one at a time. -Sara
Re: [PHP-DEV] [RFC] Function pipe operator
A questions and a comment: 1. How will XDEBUG handle a multiline construct such as this? Will it treat as one expression, or allow breakpoints at each "link" in the pipe chain? Maybe this is a better question for Derek Rethans? 2. The exclusive use of callable seems problematic prior to an inclusion a '::function' operator that can be applied to functions for symbol resolution to function name as it will encourage more use of strings that are not checked by PHP. Maybe we could address that first? Also #2 would be true for method names although how that might be implemented is a bit more complicated. -Mike > On Apr 20, 2020, at 9:38 PM, Larry Garfield wrote: > > Hello fine people of Internals! > > I've been commenting on other RFCs enough lately that I should probably put > myself through the wringer, too. I therefore offer this RFC to add a > function pipe operator, as seen in a number of other languages: > > https://wiki.php.net/rfc/pipe-operator-v2 > > A patch is available here: > > https://github.com/php/php-src/pull/5425 > > Although I have one or two bits of it that I could use feedback on. (Let me > know over on GitHub.) > > It's deliberately a very small, lightweight, and targeted change. The Future > Work section suggests possible additions for later, but this is as much as my > meager skills can manage for the moment. > > My enormous thanks to Sammy K Powers and Levi Morrison for their copious > hand-holding in my first foray into php-src. > > *dons flame retardant suit* > > -- > Larry Garfield > la...@garfieldtech.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Function pipe operator
> On Apr 20, 2020, at 20:38, Larry Garfield wrote: > > Hello fine people of Internals! > > I've been commenting on other RFCs enough lately that I should probably put > myself through the wringer, too. I therefore offer this RFC to add a > function pipe operator, as seen in a number of other languages: > > https://wiki.php.net/rfc/pipe-operator-v2 > > A patch is available here: > > https://github.com/php/php-src/pull/5425 > > Although I have one or two bits of it that I could use feedback on. (Let me > know over on GitHub.) > > It's deliberately a very small, lightweight, and targeted change. The Future > Work section suggests possible additions for later, but this is as much as my > meager skills can manage for the moment. > > My enormous thanks to Sammy K Powers and Levi Morrison for their copious > hand-holding in my first foray into php-src. > > *dons flame retardant suit* I liked the use of expressions in the v1 proposal, but I agree with you that the use of callables simplifies the approach, and (IMO) provides a better developer experience, since I found the `$$` placeholder confusing. I’m a +1 for this. I can’t wait to use it. Cheers, Ben signature.asc Description: Message signed with OpenPGP
[PHP-DEV] [RFC] Function pipe operator
Hello fine people of Internals! I've been commenting on other RFCs enough lately that I should probably put myself through the wringer, too. I therefore offer this RFC to add a function pipe operator, as seen in a number of other languages: https://wiki.php.net/rfc/pipe-operator-v2 A patch is available here: https://github.com/php/php-src/pull/5425 Although I have one or two bits of it that I could use feedback on. (Let me know over on GitHub.) It's deliberately a very small, lightweight, and targeted change. The Future Work section suggests possible additions for later, but this is as much as my meager skills can manage for the moment. My enormous thanks to Sammy K Powers and Levi Morrison for their copious hand-holding in my first foray into php-src. *dons flame retardant suit* -- Larry Garfield la...@garfieldtech.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020, at 10:45 AM, Benjamin Eberlei wrote: > > Sure, but how often is that an actual description of what the code > > accepts? I... cannot actually envision what code would actually accept > > that mess. :-) > > > > I can think of quite a few: > > - var_dump, print_r, more generally debugging/logging functions and > wrappers thereof > - json_encode, serialize, and more generally serialization and encoding > functions, as return value as well for the inverse operations > - database/nosql related functions (bindParam, bindValue) and as return > value from generic functions like fetch() > - Xpath::evaluate > - ldap query functions > > And wrappers of these extensions could benefit from passing on the mixed > type explicitly. Valid examples. It would be helpful to add those to the RFC for clarity. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open
Hey Andrea, On Mon, Apr 20, 2020, 23:25 Andrea Faulds wrote: > Hi, > > Benjamin Eberlei wrote: > > Hello, > > > > I have opened the vote on the Attributes v2 RFC. The voting will be open > > until two weeks from now, May 4th 2020, noon UTC. > > > > RFC: https://wiki.php.net/rfc/attributes_v2 > > > > Thank you everyone for taking part in the detailed discussion. > > > > greetings > > Benjamin > > > > Thanks for putting this to a vote. I remember I had some comments about > autoloading behaviour and you changed the behaviour in the RFC, but I > didn't get around to reading it again. I am concerned though that it > doesn't seem to say anymore when autoloading happens, if at all? Can > that be clarified? > > Thanks, > Andrea > >From my review of the tests, autoloading occurs when an object is being requested (via `newInstance()` call on a reflection attribute). Until then, the same semantics as the `::class` pseudo-constant apply. >
[PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open
Hi, Benjamin Eberlei wrote: Hello, I have opened the vote on the Attributes v2 RFC. The voting will be open until two weeks from now, May 4th 2020, noon UTC. RFC: https://wiki.php.net/rfc/attributes_v2 Thank you everyone for taking part in the detailed discussion. greetings Benjamin Thanks for putting this to a vote. I remember I had some comments about autoloading behaviour and you changed the behaviour in the RFC, but I didn't get around to reading it again. I am concerned though that it doesn't seem to say anymore when autoloading happens, if at all? Can that be clarified? Thanks, Andrea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DISCUSSION] Match expression
Hi Rowan If we were to remove blocks we'd probably also reconsider other things (namely the optional semicolon and break/continue) and many examples in the RFC would become invalid and irrelevant. This would probably lead to even more confusion which is why I will most likely not move blocks to an additional vote. However, I will definitely include a poll to find out why it failed. I am committed to getting this into the language, in some form or another. Regards, Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [DISCUSSION] Match expression
On 20/04/2020 19:19, Ilija Tovilo wrote: Just a heads up, I'd like to start the voting on the match expression RFC in a couple of days. https://wiki.php.net/rfc/match_expression I have made a number of changes to the RFC. * Block return values are now allowed but limited to match arms (https://wiki.php.net/rfc/match_expression#blocks) [...] If you have anything new to add to the discussion, this is your chance! Would you consider making the block support an additional vote? Alternatively, if the RFC as proposed doesn't pass, would you be willing to propose a version without this? If not, I might be inclined to do so, because I know I'm not alone in liking the expression part as a standalone feature, without the complexity of using it as a flow-control statement as well. 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: [DISCUSSION] Match expression
Hi internals Just a heads up, I'd like to start the voting on the match expression RFC in a couple of days. https://wiki.php.net/rfc/match_expression I have made a number of changes to the RFC. * Block return values are now allowed but limited to match arms (https://wiki.php.net/rfc/match_expression#blocks) * Nikita and I have discussed this here: https://github.com/php/php-src/pull/5407 * continue targeting match is no longer allowed (compilation error) (https://wiki.php.net/rfc/match_expression#breakcontinue) * Minor rewording The jury is still out on: * Optional semicolon when using match as a statement (https://wiki.php.net/rfc/match_expression#semicolon) * It makes the grammar somewhat complicated * Nesting match expression blocks without parentheses aren't possible (https://github.com/php/php-src/pull/5407#issuecomment-616612763) * Compilation error when not returning a value from a block (https://wiki.php.net/rfc/match_expression#blocks) * When the block terminates (e.g. through throw or exit) no return value is needed but the current implementation requires it * We could make this a runtime error instead If you have anything new to add to the discussion, this is your chance! Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
As Larry was asking for an example. The ParameterBag::get() function from Symfony (and others) that allows you to fetch request params, for example. That's a mixed type that could return different values, depending on your request body. Yes, I can type for all possible scalar values + null + array, but that's a bit of a PITA and phpstan would complain nonetheless, as the return type of theParameterBag ::get() function is "mixed" and we can't change that. Right now we're annotating "mixed" with a docblock. So yes, a "mixed" type is greatly appreciated when dealing with user input. Thanks! On Mon, Apr 20, 2020 at 6:41 PM Guilliam Xavier wrote: > On Mon, Apr 20, 2020 at 5:17 PM Larry Garfield > wrote: > > > > With union types and stringable already on the way, I'm not sure what > other non-hypothetical use cases would still be that fugly that you'd now > need to fall back to `mixed`. > > For instance: > - the parameter of [a wrapper around] gettype() or an is_* function > - the return of [a generic implementation of] > ArrayAccess::offsetGet() or Iterator::current(), or of a userland > array_value_first() or array_value_last() function > > To me, especially the return type declaration can be useful to ensure > that [every code path of] the implementation returns a value. > > -- > Guilliam Xavier > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Mixed type
> > But how would this work for serializing resources, which is part of mixed? > https://3v4l.org/n9D2S The point is that many internal functions accept all types (including resources), even though they might not do much useful with some of them. Besides the functions that Benjamin mentioned, I'd add the *printf family that accept "mixed" parameters to the list. Seems to me exactly this case would benefit from a, albeit long though > more accurate, actual union type. Regarding accuracy, I believe the more types you have in an union type, the less important exact accuracy is, at least for return types and properties. For example if a function has a return type of mixed, I don't consider it a big deal if the implementation doesn't actually return 1 type (e.g. resource, null) in practice. Máté
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020 at 5:17 PM Larry Garfield wrote: > > With union types and stringable already on the way, I'm not sure what other > non-hypothetical use cases would still be that fugly that you'd now need to > fall back to `mixed`. For instance: - the parameter of [a wrapper around] gettype() or an is_* function - the return of [a generic implementation of] ArrayAccess::offsetGet() or Iterator::current(), or of a userland array_value_first() or array_value_last() function To me, especially the return type declaration can be useful to ensure that [every code path of] the implementation returns a value. -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
Hi, just picking on one of the examples: On 20.04.20 17:45, Benjamin Eberlei wrote: - json_encode, serialize, and more generally serialization and encoding functions, as return value as well for the inverse operations But how would this work for serializing resources, which is part of mixed? Seems to me exactly this case would benefit from a, albeit long though more accurate, actual union type. Hope that makes sense, - Markus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020 at 4:15 PM Sara Golemon wrote: > > For the long term good of the language I'd prefer type aliases (or typedefs > or usings or whatever you want to call them. > > use mixed = null|bool|int|float|string|array|object|resource; > use scalar = null|bool|int|float|string; > use number = int|float; > > That said, baking 'mixed' in as an implicit alias of the above isn't > problematic for that future. The `scalar` example should be `bool|int|float|string`, without `null`. And for `mixed`, as already said, we cannot use `resource` in union types. All the more reason to standardize those "aliases" in core? -- Guilliam Xavier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
Hi Larry, > Sure, but how often is that an actual description of what the code > accepts? I... cannot actually envision what code would actually accept > that mess. :-) > For example the recently added get_debug_type() function does, along with dozens of internal functions. Besides messy code, I'm sure that there are legitimate use-cases for the mixed type in user-land as well. use mixed = null|bool|int|float|string|array|object|resource; > use scalar = null|bool|int|float|string; > use number = int|float; I'm really not a fan of type aliases (at least user-land ones), but I also agree with Sara that these 3 "global" aliases would come handy. Actually, I was considering to also propose "scalar" and "number" in a later RFC. Cheers, Máté
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020 at 5:17 PM Larry Garfield wrote: > On Mon, Apr 20, 2020, at 9:15 AM, Sara Golemon wrote: > > On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield > > wrote: > > > > > On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote: > > > > Here is an RFC for adding a 'mixed' type to the language: > > > > https://wiki.php.net/rfc/mixed_type_v2 > > > > > > > > > > I am not against this, but now that we have Union types what places are > > > there where the currently available type declarations are insufficient? > > > Resource seems like the only remaining gap where you'd be forced to use > > > `mixed` instead of a union. > > > > > > I imagine some type combinations get pretty wide. Like, this is > verbose AF. > > > > null|bool|int|float|string|array|object|resource > > Sure, but how often is that an actual description of what the code > accepts? I... cannot actually envision what code would actually accept > that mess. :-) > I can think of quite a few: - var_dump, print_r, more generally debugging/logging functions and wrappers thereof - json_encode, serialize, and more generally serialization and encoding functions, as return value as well for the inverse operations - database/nosql related functions (bindParam, bindValue) and as return value from generic functions like fetch() - Xpath::evaluate - ldap query functions And wrappers of these extensions could benefit from passing on the mixed type explicitly. > With union types and stringable already on the way, I'm not sure what > other non-hypothetical use cases would still be that fugly that you'd now > need to fall back to `mixed`. (I still think intersection types are > needed, but that's a separate matter.) There may be, but I cannot think of > them. > > > For the long term good of the language I'd prefer type aliases (or > typedefs > > or usings or whatever you want to call them. > > > > use mixed = null|bool|int|float|string|array|object|resource; > > use scalar = null|bool|int|float|string; > > use number = int|float; > > Concur. > > > That said, baking 'mixed' in as an implicit alias of the above isn't > > problematic for that future. > > > > -Sara > > Concur. > > --Larry Garfield > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020, at 9:15 AM, Sara Golemon wrote: > On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield > wrote: > > > On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote: > > > Here is an RFC for adding a 'mixed' type to the language: > > > https://wiki.php.net/rfc/mixed_type_v2 > > > > > > > I am not against this, but now that we have Union types what places are > > there where the currently available type declarations are insufficient? > > Resource seems like the only remaining gap where you'd be forced to use > > `mixed` instead of a union. > > > > I imagine some type combinations get pretty wide. Like, this is verbose AF. > > null|bool|int|float|string|array|object|resource Sure, but how often is that an actual description of what the code accepts? I... cannot actually envision what code would actually accept that mess. :-) With union types and stringable already on the way, I'm not sure what other non-hypothetical use cases would still be that fugly that you'd now need to fall back to `mixed`. (I still think intersection types are needed, but that's a separate matter.) There may be, but I cannot think of them. > For the long term good of the language I'd prefer type aliases (or typedefs > or usings or whatever you want to call them. > > use mixed = null|bool|int|float|string|array|object|resource; > use scalar = null|bool|int|float|string; > use number = int|float; Concur. > That said, baking 'mixed' in as an implicit alias of the above isn't > problematic for that future. > > -Sara Concur. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020 at 8:52 AM Larry Garfield wrote: > On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote: > > Here is an RFC for adding a 'mixed' type to the language: > > https://wiki.php.net/rfc/mixed_type_v2 > > > > I am not against this, but now that we have Union types what places are > there where the currently available type declarations are insufficient? > Resource seems like the only remaining gap where you'd be forced to use > `mixed` instead of a union. > > I imagine some type combinations get pretty wide. Like, this is verbose AF. null|bool|int|float|string|array|object|resource For the long term good of the language I'd prefer type aliases (or typedefs or usings or whatever you want to call them. use mixed = null|bool|int|float|string|array|object|resource; use scalar = null|bool|int|float|string; use number = int|float; That said, baking 'mixed' in as an implicit alias of the above isn't problematic for that future. -Sara
Re: [PHP-DEV] [RFC] Mixed type
On Mon, Apr 20, 2020, at 6:17 AM, Dan Ackroyd wrote: > Hi Internals, > > Here is an RFC for adding a 'mixed' type to the language: > https://wiki.php.net/rfc/mixed_type_v2 > The RFC builds on an earlier draft by Michael Moravec. > > Part of the motivation for pursuing this RFC was my recent experience > in upgrading an application to PHP 7.4. > > Being able to add types to the application made the code much easier > to reason about, but there were places where I couldn't add type info > due to the lack of mixed. That made it hard to see if that piece of > code had been upgraded (but type info couldn't be added), or if that > code still needed to be upgraded. > > cheers > Dan > Ack I am not against this, but now that we have Union types what places are there where the currently available type declarations are insufficient? Resource seems like the only remaining gap where you'd be forced to use `mixed` instead of a union. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Attributes v2 RFC Vote is open
On Mon, Apr 20, 2020 at 4:18 AM Benjamin Eberlei wrote:
> I have opened the vote on the Attributes v2 RFC. The voting will be
> open until two weeks from now, May 4th 2020, noon UTC.
>
> RFC: https://wiki.php.net/rfc/attributes_v2
It's unfortunate that the RFC doesn't more fully enumerate the
advantages/disadvantages of the proposed syntax options.
It only points out that the T_ATTRIBUTE `@:` syntax is shorter and
more familiar, but claims that it has the downside of not permitting
whitespace in attribute names (it's not clear this is really an
advantage - just an opportunity for arguments about code style).
But if you look at the pull request for the `@:` syntax [1], there is
a much more complete comparison. For example, the `<<>>` syntax is more
verbose, unfamiliar to most people, and even Hack seems to be moving
away from it. Furthermore, because it reuses existing tokens with a
different meaning, it results in expressions that can be very difficult
to read. For example:
```php
const Baz = 2;
<><>
<>Baz, (4 + 5) * 2)>>
function foo() {}
```
If PHP gets generics in the future (hopefully it does), the syntax will
likely get even more confusing (if not a lot of PHP developers use shift
tokens, certainly a lot more will use generics).
The `@:` syntax makes it much more obvious where separate attributes
are being used vs. constant expressions containing a shift token:
@:FooAttribute(2 * 3 + 3)
@:Bar(4 + 5 * 2)
@:BarAttribute(2 * (3 + 3)>>Baz, (4 + 5) * 2)
function foo() {}
```
In addition, the `@:` syntax is less verbose, and much closer to the
attribute syntax developers are familiar with using in PHPDoc comments,
as well as the syntax with precedence in other languages such as Java
and Python.
The syntax choice is very important, the language will be stuck with
it for a very long time!
Best regards,
Theodore
[1]: https://github.com/kooldev/php-src/pull/2
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] PHP Namespace in core
Hi Michał, George, On Wed, Apr 15, 2020 at 2:29 PM Michał Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi internals, > > I hope you're doing well. > > I'd like to announce the PHP Namespace in core RFC for discussion. > The RFC is authored by me together with George Peter Banyard and it's > purpose > is nothing more like to allow the use of PHP Namespace in the core. > > The RFC is described at https://wiki.php.net/rfc/php-namespace-in-core I think the php namespace for core is important to have, especially for features that have more than a single, but multiple classes, grouping them in a PHP internal namespace will be helpful to avoid weird prefixing. With the Attributes RFC in mind, an earlier draft has used the namespace PHP\Attributes that a few contributors rightly mentioned is a bad idea without project wide standardization first. For my taste, the RFC is great except the "A chance to clean up poor design/naming decisions" section. It goes into politics and controversial ideas that essentially are outside the scope of the RFC itself. So while SPL and Reflection would benefit if we had the namespace before those APIs, I am not sure they drive down the point of why we need this: a.) Instead of changing SPL I believe most would pretty much agree that we just need a complete replacement with a better API (pointing towards phpds here might be a better example) b.) Moving some new parts of Reflection into the namespace while keeping others in the main namespace is extremely confusing, and we shouldn't confuse users that way. Realistically this is an issue thats not going to be changed. I do like the Frame example, similar to token_get_all returning an array, debug_backtrace could benefit from an object based representation. I would reluctantly call it a "toy example", it is an actual example or not? greetings Benjamin > > > Best Regards, > Michał Brzuchalski >
[PHP-DEV] [RFC] Mixed type
Hi Internals, Here is an RFC for adding a 'mixed' type to the language: https://wiki.php.net/rfc/mixed_type_v2 The RFC builds on an earlier draft by Michael Moravec. Part of the motivation for pursuing this RFC was my recent experience in upgrading an application to PHP 7.4. Being able to add types to the application made the code much easier to reason about, but there were places where I couldn't add type info due to the lack of mixed. That made it hard to see if that piece of code had been upgraded (but type info couldn't be added), or if that code still needed to be upgraded. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Attributes v2
Hi Niklas, On Mon, 20 Apr 2020 at 07:48, Niklas Keller wrote: > > What's more important here IMO is the restriction of inheritance, > mainly because the raw arguments are exposed via reflection and won't > be compatible between parent and child attribute in any case. > Could you explain a bit more about the problem you see here? My understanding is that the reflection API is designed to allow two usage styles: * Treating attributes as untyped mappings from a name to a list of arguments (fetch all, or filter by exact name, then call getName() and getArguments()) * Treating attributes as classes instantiated with the argument given (filter by INSTANCE_OF, then call newInstance(), formerly called getAsObject()) For the first style, inheritance doesn't matter, because the attribute name is never resolved as a class anyway, it's just an identifier (it might happen to look like one, to avoid naming collisions, in the same way XML namespaces look like URLs). For the second style, it's up to the user to provide the right arguments for the attribute they used, just as it would be if they instantiated it directly with the "new" keyword. The only case I can see where incompatible constructors would be a problem would be if someone filtered by INSTANCE_OF, and then called getArguments() and expected them to be consistent rather than using newInstance(), but I'm not sure why anyone would want to do that, so a one line note in the manual pointing out it's a bad idea would seem sufficient. But perhaps I'm missing something more fundamental that makes you feel that inheritance should be restricted? Regards, -- Rowan Tommins [IMSoP]
[PHP-DEV] [VOTE] Attributes v2 RFC Vote is open
Hello, I have opened the vote on the Attributes v2 RFC. The voting will be open until two weeks from now, May 4th 2020, noon UTC. RFC: https://wiki.php.net/rfc/attributes_v2 Thank you everyone for taking part in the detailed discussion. greetings Benjamin
Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with function
On Mon, Apr 20, 2020 at 5:59 AM wrote: > Hello, > > I have opened voting for the str_starts_with and str_ends with RFC. The > voting will be open until two weeks from now, 2020-05-04. > > RFC: > https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions > > Please vote, thanks! > Thanks for picking this up again. This will nicely complement the str_contains function already accepted for PHP 8. Nikita
Re: [PHP-DEV] Re: [RFC] Attributes v2
Hey Benjamin, thanks for your answers! > <> would best require a namespace (PHP\Attributes) as I feel > claminig "Attribute" class in the main namespace might cause problems for > users. While this is true, I don't see how Attribute is different to any classes introduced in the "recent" versions like \Generator or \Error. Maybe Nikita can run his analyzer to see how widespread its usage is? > But there is no PHP namespace yet and proposals about this have just > gotten to the list. I have therefore looked to PhpToken from nikitas recent > RFC as an example for naming, because several contributors mentioned that > the PHP\Attributes namespace I suggested in an earlier version of the RFC > would be an instant "no" vote, because of the lack of previous decision on > this topic. Some prefix is pretty similar to a namespace, and I don't like a new naming convention being part of this RFC. For PhpToken the naming might make sense, as "Token" alone might be seen as a too generic term. > The reason these are plain PHP objects and not some special case is that > you can re-use them for configuration from different sources. Symfony > Validator is a good example where the "attributes" could map to the > validator configuration classes that are also used from XML, YAML, ... Sounds fine! > Yes, INSTANCE_OF attempts to load each attributes class, but if an > attribute class cannot be looked up (not autoloadable) it gets skipped > without error (subject to error handling of autoloader implementation, but > for Composer it skips). This seems rather strange to me, but I can definitely see the value if you're using no-dev deployments, for example. I think I'd be better to disallow inheritance for attributes and skip the autoloading and INSTANCE_OF parameter here. > > > > I expect annotations to be readonly, which classes as outlined in the > > RFC cannot currently enforce in PHP. A syntax similar to interfaces > > might be appropriate, I'm not sure whether that has been discussed: > > > > The write-once / readonly RFC was rejected and only internal classes can > implement this behavior (see ext/dom). But userland attributes also map to > userland classes, so as you say this is not possible. However given this > RFC maps to existing concepts. I'd be possible if the actual objects are created in core and userland only provides the contracts (interfaces) for these attributes. > I don't see how preventing instantiation or requiring readonly in userland > produces any benefits over this described use-case in the RFC. This would > make attributes much stricter than everything else in the language, I don't > see how its fair to impose this on a new feature like Attributes, when the > language doesn't even have concepts for this strictness for regular classes > (containing more important code). Mapping to "normal" classes is the way C# > implements attributes, I don't think this should be more complex than that. Readonly is just something I'd like to see, it's not a requirement and I'll still vote yes if the more important points are solved. What's more important here IMO is the restriction of inheritance, mainly because the raw arguments are exposed via reflection and won't be compatible between parent and child attribute in any case. There are a few options I see to solve this: - Require constructor compatibility for attribute classes (only other classes) - Forbid extending attribute classes entirely - Remove getArguments() from reflection I think my preferred solution would be to forbid inheritance, because that also solves the autoloading inconsistencies (given that implemented interfaces aren't respected in `ReflectionFunction::getAttributes()` and others. > Extensions, and Third Party library authors can easily guard their > attribute classes against writes from the outside with the usual OOP > abstractions and if application authors deem their attributes to be > writable that is their business. That's probably fine, yes, if `getAsObject()` / `toObject()` / `createObject()` always returns a new object. > Named parameters might some day come to PHP in the future, and this is > precisely the argument for treating an attribute like a regular php class > with a constructor, because the named params syntax would look exactly the > same in attribute declarations then, increasing language consistency. > > The reason I went with the C# way of mapping to a "plain class" is > simplicity. The concept of attributes is already not the easiest nut to > crack, inventing another keyword and a structure that looks like a class, > but has very different implications requires a lot of words in the > documentation and doesn't provide the easiest access to beginners. I guess writing your own annotations and processing them isn't a beginners topic, but using them to attribute code definitely is. > > > > Finally, the naming of "getAsObject" should IMO be improved, > > especially if I read the RFC correctly and autoloading
