Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy
On Fri, Apr 24, 2020 at 6:09 PM Mark Randall wrote: > On 25/04/2020 00:00, Michael Morris wrote: > > So, in steps: > > > > 1. Take the current function roster - all of it - and put it in > > \PHP\Legacy\. So the formal name of strpos would become > > \PHP\Legacy\strpos. > > 2. The root namespace would be empty BUT... > > 3. An INI directive set globally or per directory can set which namespace > > is bound to root. Initially this would be "\PHP\Legacy", so all legacy > > code would not have to change - it would run in the new version and find > > all of its functionality without incident. This is critical - as this > > directive would likely need to stay as is for two majors minimum, > possibly > > more. > > Thank you for the contribution. > > However, such a change would never, ever be accepted. With good reason. > > Mark Randall > marand...@php.net > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > What good reason? Because it is hard?
Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy
On 25/04/2020 00:00, Michael Morris wrote: So, in steps: 1. Take the current function roster - all of it - and put it in \PHP\Legacy\. So the formal name of strpos would become \PHP\Legacy\strpos. 2. The root namespace would be empty BUT... 3. An INI directive set globally or per directory can set which namespace is bound to root. Initially this would be "\PHP\Legacy", so all legacy code would not have to change - it would run in the new version and find all of its functionality without incident. This is critical - as this directive would likely need to stay as is for two majors minimum, possibly more. Thank you for the contribution. However, such a change would never, ever be accepted. With good reason. Mark Randall marand...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] PHP Namespace Policy
On Thu, Apr 23, 2020 at 9:48 AM Mark Randall wrote: > On 15/04/2020 12:21, Mark Randall wrote: > > https://wiki.php.net/rfc/php_namespace_policy > > Just an update in light of the two different RFCs. > > Having chatted with the other RFC authors in R11, rather than racing to > see who can get their RFC to vote first, it seems like there's room for > both. > > Vote 1 would be the other RFC which would be something along the lines of: > > "Mandate the use of \PHP for future internal tightly-bound components" > > If vote 1 were passed, the next vote would be on this RFC, and would > cover policy on namespace usage and would be something like: > > "The \PHP namespace must remain empty, except for child namespaces". > > This would be to prevent the problem of colliding internals symbols > throughout the rest of PHP's maintained lifespan (such as what if there > was something else added to core called Token). > > Vote 3 would mandate only autoloadable classes / interfaces / traits etc > etc were used, allowing userland polyfills (where sensible) to provide a > route for users to begin using newer API functionality without an > immediate upgrade. > > Votes 1 and 2 passing would put us on a pretty good course for long-term > sanity. > > Vote 1 passing and 2 failing would result in part of the problem just > being moved to \PHP and exposing us to symbol collision further down the > line. > > If vote 1 failed, we would have to consider if this RFC would pass with > its tigher constraints. > > The question is, how would we vote on extra uses for PHP. > > While the alternative RFC mandates its use for tightly coupled, I think > it makes a lot of sense to add extra things to it, such as re-designed > collections (borg Ds?) in \PHP\Collections in a similar fashion to: > > > https://docs.microsoft.com/en-us/dotnet/api/system.collections?view=netframework-4.8 > > > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > I would like to submit from the peanut gallery of user land. My perspective here is as a user, not as an internals writer. I also have no formal training so I can bring that perspective to the table for consideration. That said, I don't represent anyone but myself. I've read the talk of how the \PHP namespace should be used and not be used. I personally think we should slow down and carefully consider what we can do here, because active assignment of the namespace will have ramifications for the rest of PHP's life. We have the opportunity to make a course change, but it won't be easy. And we only really get one good shot at this. All of PHP's core functionality is currently in \. All of it. That makes the language easy to pick up and learn, but the functions in that namespace are, well, idiosyncratic. Are the arguments in (haystack, needle) order or (needle, haystack). Is the function camelCase or underscore_delimited or neitherone? Changing function names and argument orders would lead to BC breaks so massive people would move away without a transition plan that was sustainable long term. Namespaces give that opportunity, I think. So, in steps: 1. Take the current function roster - all of it - and put it in \PHP\Legacy\. So the formal name of strpos would become \PHP\Legacy\strpos. 2. The root namespace would be empty BUT... 3. An INI directive set globally or per directory can set which namespace is bound to root. Initially this would be "\PHP\Legacy", so all legacy code would not have to change - it would run in the new version and find all of its functionality without incident. This is critical - as this directive would likely need to stay as is for two majors minimum, possibly more. And yes, I'm keenly aware of the scope of this. The RFC system itself would need to be changed to allow this to be possible since this approach demands a design be submitted, approved and THEN an implementation written and approved. Difficult, but not impossible - the W3C does this all the time. Even with a Design, then implement RFC system in place, I imagine a full year would be needed just to get the designs down and agreed upon. The best PHP 8 could do is just lay the foundation for transition outlined above and not actually include any alternative to \PHP\Legacy The rest of \PHP\ would be the replacements for the legacy pieces. It needs to be a designed library with a consistent naming schema and argument orders, at a minimum. It also needs to be broken up so as not to overwhelm the developers doing the implementation. We might even end up with some duplication to satisfy the procedural vs. object oriented camps. The new functions would also have a freer hand since they are opted into. Beyond that though I don't really think it's helpful for me to go into more detail because I'm not a language designer. I know enough to know I don't know enough to give this subject a thorough vetting at this time (I could certainly learn).
Re: [PHP-DEV] Typed callable properties
Hello, I would like to correct myself (credits to Marco Pivetta for informing me) regarding union types. While we still wouldn't be able to declare a type alias as `callable` and then use it in properties, technically speaking `string|array|object` would allow to pass callables. As such, my point about union types is invalid. Best regards, Benas Seliuginas ‐‐‐ Original Message ‐‐‐ On Wednesday, April 22, 2020 7:56 PM, moliata wrote: > Hello, > > thank you for your opinion. In response to you mentioning that fixing this > problem would be a huge amount of work, I would like to reiterate the idea of > simply ignoring context-dependent problems for the time being. In fact, we can > observe this behavior in parameter/return type hints already. As such, it > doesn't make sense to make just property type hints a special case/exception. > > Moreover, I oversaw Sara Golemon's comment in the `mixed pseudo type` RFC that > she would like to use type aliasing and union types instead, at least in the > long run. The problem that comes up with this approach is that even if we did > something like this: > `use mixed as string|int|...|callable;` > ...we couldn't apply this `mixed` type alias to properties as callable type is > not allowed to be used with them. > > Best regards, > Benas Seliuginas > > ‐‐‐ Original Message ‐‐‐ > On Wednesday, April 22, 2020 5:29 PM, Dan Ackroyd dan...@basereality.com > wrote: > > > On Tue, 21 Apr 2020 at 14:08, moliata moli...@protonmail.com wrote: > > > > > > > > > > I wanted to ignite a friendly discussion whether > > > PHP should allow typed callable properties. > > > > IMO no. > > Trying to fix the problems with callables would be a huge amount of > > work, and not actually give that much benefit. Even just documenting > > the problems with callables* is a non-trivial amount of work, and I > > suspect there are many horrors lurking with the SPL code related to > > them. > > > > > I believe we should look into... > > > > I'm pretty sure that choosing a different problem to solve that: > > > > - would be easier to solve. > > > > - provide more benefit in the long term. > > > > - not require breaking a lot of userland + internal code immediately, > > but instead allow for migration over a longer period. > > My thoughts on adding 'function types' are here: > > https://github.com/Danack/FunctionTypes/blob/master/function_type_rfc.md > > There's still more than a couple of known problems that need to be > > worked through, as well as probably unknown problems lurking. As email > > is not a good format for carrying out discussions, if people want to > > take part in that discussion, doing it in that repo would be better > > imo. > > Assuming the problems remaining can be addressed, that would give us a > > more useful feature, and the existing 'callables' can be slowly > > deprecated and maybe removed from PHP in the distant future. > > cheers > > Dan > > Ack > > *[problems with callables] - > > https://wiki.php.net/rfc/consistent_callables > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
Hello, I did some tests and in fact it seems you're right. Thank you for letting me know, didn't know! Best regards, Benas Seliuginas ‐‐‐ Original Message ‐‐‐ On Friday, April 24, 2020 6:44 PM, Marco Pivetta wrote: > Hey moliata, > > On Fri, Apr 24, 2020 at 5:27 PM moliata moli...@protonmail.com wrote: > > > Actually, it's not quite possible to declare a `mixed` type using union > > types given that it's not possible to make properties as callable (please > > take a look at my "Typed callable properties" post in the mailing list). As > > such, if we wanted to make a property hold a callable, we would have to > > fallback to just not using a type hint at all. > > Correct me if I'm wrong but this behavior is addressed in the RFC and we > > can pass callables to properties that are declared as `mixed`, right? > > The only limitation right now is`resource`: `callable` is always either an > `array`, a `string` or an `object` that implements `__invoke`, so > `callable` is a subtype of the union type mentioned few posts above. > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
Hey moliata, On Fri, Apr 24, 2020 at 5:27 PM moliata wrote: > Actually, it's not quite possible to declare a `mixed` type using union > types given that it's not possible to make properties as callable (please > take a look at my "Typed callable properties" post in the mailing list). As > such, if we wanted to make a property hold a callable, we would have to > fallback to just not using a type hint at all. > > Correct me if I'm wrong but this behavior is addressed in the RFC and we > can pass callables to properties that are declared as `mixed`, right? > The only limitation right now is `resource`: `callable` is always either an `array`, a `string` or an `object` that implements `__invoke`, so `callable` is a subtype of the union type mentioned few posts above. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC] Mixed type
Actually, it's not quite possible to declare a `mixed` type using union types given that it's not possible to make properties as callable (please take a look at my "Typed callable properties" post in the mailing list). As such, if we wanted to make a property hold a callable, we would have to fallback to just not using a type hint at all. Correct me if I'm wrong but this behavior is addressed in the RFC and we can pass callables to properties that are declared as `mixed`, right? Best regards, Benas Seliuginas ‐‐‐ Original Message ‐‐‐ On Friday, April 24, 2020 6:09 PM, Matthew Brown wrote: > > How much would you like/be adverse to a rector rule that changes `mixed` > > into a long union type (without `resource` in it)? > > > Considering above posts, `mixed` is effectively > > `null|bool|string|int|float|array|object|resource`, > > At runtime those things are effectively the same, but in the world of types > mixed has its own distinct meaning – I'd be very averse to any sort of > corresponding replacement. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
I personally would stick to `mixed`. It's used extensively in the official PHP
documentation and has grown with the language. Heck, even static analysis tools
and billions of PHPDoc comments (e. g. Laravel, CakePHP, Yii) use `mixed` type.
Switching to `any` just doesn't feel right.
Oh and well, I also think that `mixed` makes more sense.
Best regards,
Benas Seliuginas
‐‐‐ Original Message ‐‐‐
On Friday, April 24, 2020 5:48 PM, Markus Fischer wrote:
> On 24.04.20 16:33, Bob Weinand wrote:
>
> > Actually,
>
> Really had to laugh, reading your previous and then this mail :-)
>
> > I forgot that for proper generics implementations, collections etc. will
> > obviously need to specify "allowing any type". As such the introduction of
> > mixed is pretty much necessary.
> > As in class Foo { … } $foo = new Foo;
> > As such, I'm actually in favor of introducing it.
>
> Re-quote:
>
> > "allowing any type"
>
> That would make the case for the`any` type instead of mixed; IMHO much
> more clear.
>
> - Markus
>
> --
> 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] Mixed type
> > How much would you like/be adverse to a rector rule that changes `mixed` > into a long union type (without `resource` in it)? > Considering above posts, `mixed` is effectively > `null|bool|string|int|float|array|object|resource`, > At runtime those things are effectively the same, but in the world of types mixed has its own distinct meaning – I'd be very averse to any sort of corresponding replacement.
Re: [PHP-DEV] [RFC] Mixed type
On 24.04.20 16:33, Bob Weinand wrote:
Actually,
Really had to laugh, reading your previous and then this mail :-)
I forgot that for proper generics implementations, collections etc. will obviously need
to specify "allowing any type". As such the introduction of mixed is pretty
much necessary.
As in class Foo { … } $foo = new Foo;
As such, I'm actually in favor of introducing it.
Re-quote:
> "allowing any type"
That would make the case for the `any` type instead of mixed; IMHO much
more clear.
- Markus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Mixed type
Actually,
I forgot that for proper generics implementations, collections etc. will
obviously need to specify "allowing any type". As such the introduction of
mixed is pretty much necessary.
As in class Foo { … } $foo = new Foo;
As such, I'm actually in favor of introducing it.
Bob
> Am 24.04.2020 um 14:11 schrieb Bob Weinand :
>
> Hey Dan,
>
> this, I consider one of the few concepts which should never make it into PHP.
>
> In particular, the main problem with mixed is that it is a very easy "I have
> no idea how to type that properly, so just let's use mixed".
>
> And really, in general, except for some debug functions, mixed is just an
> excuse to not use proper generics. I cannot think of non-debug scenarios
> where we are juggling truly unknown types where the type is unidirectional.
> (Uni-directional means: there is no corresponding getting/forwarding function
> for an input.)
>
> Mixed is in almost every case just patching the holes in PHPs type system.
> And as such, I'd rather promote RFCs trying to properly fix the gaps in the
> type system than supporting mixed.
>
> Mixed is a hack, do not use mixed.
>
> Bob
>
> P.s.: If you want to migrate your types and have an overview of what's
> already migrated, maybe just add a comment // type-migrated before or
> similar? But that's seriously not the business of the language.
>
>> Am 20.04.2020 um 13:17 schrieb Dan Ackroyd :
>>
>> 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
>>
>
> --
> 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] Mixed type
Hey Dan, On Mon, Apr 20, 2020, 13:18 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. > How much would you like/be adverse to a rector rule that changes `mixed` into a long union type (without `resource` in it)? Considering above posts, `mixed` is effectively `null|bool|string|int|float|array|object`, and that the language has the ability to use this type in 8.0, I think making `mixed` very painful to write may be a big advantage. `resource` is still a massive PITA: not sure if it can be removed within the decade. Heck, we may even deprecate signature-less parameters and return types in a very far future 💪 >
Re: [PHP-DEV] [RFC] Mixed type
> > I'm not as strongly against adding "mixed" to the language as Bob, but I'm > not convinced I'd ever bother using it. > I'm opposed to the use mixed in codebases – I try as best I can to remove it from any code I come across, and a static analysis tool I've built flags the use of mixed types whenever a more specific type is preferable. I even have an opt-in website devoted to tracking the percentage of non-mixed types in open-source projects, e.g. https://shepherd.dev/github/sebastianbergmann/phpunit Nevertheless, I think mixed should be available as a type hint for the extreme cases mentioned in this thread (e.g. serialisation). A type system without an explicit mixed type feels incomplete to me.
Re: [PHP-DEV] [RFC] Mixed type
On Fri, 24 Apr 2020 at 13:18, Lynn wrote: > I would love to see mixed being added as it lets me remove a lot of > docblocks that are only added so I can indicate mixed. I disagree that it's > patching holes, it's filling a gap that's currently missing something. > I realise it's partly a matter of style, but if I were benevolent dictator of a legacy code base, I'd prefer to keep the docblocks, and mandate that all uses of "mixed" should include a comment describing what the parameter / return type represents / is related to. Similarly, I wouldn't delete a docblock for a return type of "array", because I'd want more specific details (either using "type[]" syntax, "list" syntax, or a comment describing the "shape" of the array). I'm not as strongly against adding "mixed" to the language as Bob, but I'm not convinced I'd ever bother using it. Regards, -- Rowan Tommins [IMSoP]
Re: [PHP-DEV] [RFC] Mixed type
On Fri, Apr 24, 2020 at 2:12 PM Bob Weinand wrote: > Mixed is in almost every case just patching the holes in PHPs type system. > And as such, I'd rather promote RFCs trying to properly fix the gaps in the > type system than supporting mixed. > > Mixed is a hack, do not use mixed. > Heya Bob, I maintain lots of legacy code and I cannot add return types despite being truly mixed. Mixed is not a hack, it's a scenario that frequently happens. There are lots of use-cases where we explicitly want to mark it as such as it truly accepts anything. Would I use it in new code? Pretty much never, as `string|int` would already cover the majority of cases, especially where ints are represented by strings. I would love to see mixed being added as it lets me remove a lot of docblocks that are only added so I can indicate mixed. I disagree that it's patching holes, it's filling a gap that's currently missing something. Regards, Lynn
Re: [PHP-DEV] [RFC] Mixed type
Hey Dan, this, I consider one of the few concepts which should never make it into PHP. In particular, the main problem with mixed is that it is a very easy "I have no idea how to type that properly, so just let's use mixed". And really, in general, except for some debug functions, mixed is just an excuse to not use proper generics. I cannot think of non-debug scenarios where we are juggling truly unknown types where the type is unidirectional. (Uni-directional means: there is no corresponding getting/forwarding function for an input.) Mixed is in almost every case just patching the holes in PHPs type system. And as such, I'd rather promote RFCs trying to properly fix the gaps in the type system than supporting mixed. Mixed is a hack, do not use mixed. Bob P.s.: If you want to migrate your types and have an overview of what's already migrated, maybe just add a comment // type-migrated before or similar? But that's seriously not the business of the language. > Am 20.04.2020 um 13:17 schrieb Dan Ackroyd : > > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
