[RFC] [DISCUSSION] Scalar Pseudo-type

  101411
December 24, 2017 14:34 php@fleshgrinder.com (Fleshgrinder)
Hi Internals!

I prepared a PR to add the `scalar` pseudo-type to PHP after the
discussions around adding a `mixed` pseudo-type. I strongly believe that
it makes sense to provide the most common primitive union types with
handy aliases even if we are going to add union types in the future to PHP.

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

I added support for parameter type covariance and return type
contravariance to make it as useful in daily development as possible.

I will provide the RFC write-up asap at:

https://wiki.php.net/rfc/scalar-pseudo-type

-- 
Richard "Fleshgrinder" Fussenegger
  101412
December 24, 2017 16:30 nikita.ppv@gmail.com (Nikita Popov)
On Sun, Dec 24, 2017 at 3:34 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> Hi Internals! > > I prepared a PR to add the `scalar` pseudo-type to PHP after the > discussions around adding a `mixed` pseudo-type. I strongly believe that > it makes sense to provide the most common primitive union types with > handy aliases even if we are going to add union types in the future to PHP. > > https://github.com/php/php-src/pull/2987 > > I added support for parameter type covariance and return type > contravariance to make it as useful in daily development as possible. > > I will provide the RFC write-up asap at: > > https://wiki.php.net/rfc/scalar-pseudo-type >
I think this RFC could benefit from displaying some use-cases for this type annotation. I can't recall any recent instance where I would have found this specific type combination useful, though I'm sure there are good examples. I also wonder whether in weak typing mode, scalar should also accept __toString objects (and cast them to string), similarly to how a bool|int|float|string union would behave. Nikita
  101413
December 24, 2017 16:42 php@fleshgrinder.com (Fleshgrinder)
On 12/24/2017 5:30 PM, Nikita Popov wrote:
> I think this RFC could benefit from displaying some use-cases for this type > annotation. I can't recall any recent instance where I would have found > this specific type combination useful, though I'm sure there are good > examples. > > I also wonder whether in weak typing mode, scalar should also accept > __toString objects (and cast them to string), similarly to how a > bool|int|float|string union would behave. > > Nikita >
I will extend it with some examples. I guess that that would be useful in weak mode. Will try to hack it in. I am currently also working on another RFC that adds a `Convertible` interface with a single `into` method that has its return type set to `scalar` where objects can opt-in to become `scalar` compatible. Even in strict mode. The idea is that the object's `into` method is automatically called by the engine and the receiver gets the canonical `scalar` value that represents the object. This is specifically useful for value objects that often represent single `scalar` values in a type safe manner. -- Richard "Fleshgrinder" Fussenegger
  101415
December 24, 2017 17:25 php@fleshgrinder.com (Fleshgrinder)
On 12/24/2017 5:42 PM, Fleshgrinder wrote:
> I will extend it with some examples. > > I guess that that would be useful in weak mode. Will try to hack it in. > > I am currently also working on another RFC that adds a `Convertible` > interface with a single `into` method that has its return type set to > `scalar` where objects can opt-in to become `scalar` compatible. Even in > strict mode. The idea is that the object's `into` method is > automatically called by the engine and the receiver gets the canonical > `scalar` value that represents the object. This is specifically useful > for value objects that often represent single `scalar` values in a type > safe manner. >
Added some examples but I will stop now working on anything because people already start complaining again. Contributing to PHP is like kicking a combat dog ... let's wait for some support for this feature in general first. -- Richard "Fleshgrinder" Fussenegger
  101416
December 26, 2017 13:38 sebastian@php.net (Sebastian Bergmann)
Am 24.12.2017 um 15:34 schrieb Fleshgrinder:
> I prepared a PR to add the `scalar` pseudo-type to PHP after the > discussions around adding a `mixed` pseudo-type. I strongly believe that > it makes sense to provide the most common primitive union types with > handy aliases even if we are going to add union types in the future to PHP.
Thank you, Richard, for working on this. I spent a lot of time this year introducing scalar type declarations into existing code bases. In quite a few cases I was not able to do so because the existing code works with parameters that can be of two or more scalar types. With PHP 7.2, I can only document this outside of the code using @param annotations (until the code has been refactored to work with only one parameter type). With a "scalar" type declaration I would not have to fall back to @param annotations and could express the type in actual syntax.
  101417
December 26, 2017 15:36 me@kelunik.com (Niklas Keller)
> > Am 24.12.2017 um 15:34 schrieb Fleshgrinder: > > I prepared a PR to add the `scalar` pseudo-type to PHP after the > > discussions around adding a `mixed` pseudo-type. I strongly believe that > > it makes sense to provide the most common primitive union types with > > handy aliases even if we are going to add union types in the future to > PHP. > > Thank you, Richard, for working on this. > > I spent a lot of time this year introducing scalar type declarations into > existing code bases. In quite a few cases I was not able to do so because > the existing code works with parameters that can be of two or more scalar > types. With PHP 7.2, I can only document this outside of the code using > @param annotations (until the code has been refactored to work with only > one parameter type). > > With a "scalar" type declaration I would not have to fall back to @param > annotations and could express the type in actual syntax. >
If you want just two of those and not all, you'd still have to use PHPdoc for those? IIRC you voted against union types, which would be a better fit in that case? Regards, Niklas
>
  101418
December 26, 2017 15:46 lists@rhsoft.net ("lists@rhsoft.net")
Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann:
> Thank you, Richard, for working on this. > > I spent a lot of time this year introducing scalar type declarations into > existing code bases. In quite a few cases I was not able to do so because > the existing code works with parameters that can be of two or more scalar > types. With PHP 7.2, I can only document this outside of the code using > @param annotations (until the code has been refactored to work with only > one parameter type). > > With a "scalar" type declaration I would not have to fall back to @param > annotations and could express the type in actual syntax
https://wiki.php.net/rfc/union_types sebastian (sebastian) - voted NO would you mind to explain this?
  101419
December 26, 2017 15:56 sebastian@php.net (Sebastian Bergmann)
Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net:
> would you mind to explain this?
"Foo|Bar", "array|string", etc. (still) make no sense to me. "scalar" makes sense to me although it is but an alias for "bool|float|int|string".
  101422
December 26, 2017 16:08 lists@rhsoft.net ("lists@rhsoft.net")
Am 26.12.2017 um 16:56 schrieb Sebastian Bergmann:
> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: >> would you mind to explain this? > > "Foo|Bar", "array|string", etc. (still) make no sense to me. > > "scalar" makes sense to me although it is but an alias for > "bool|float|int|string".
honestly *that* makes no sense for me with "float|int" you would have no need for dozens of aliases, in that case "numeric" when i expect some number but not a string and not a boolean return by a strpos() or similar functions also i have function which allows "int|array" where the internal logic loops the array internally but i don't want a random boolean or string there it's all about express accepted types as strict as possible in code to find errors early and in strict_types mode even the caller which needs to be fixed in the stack-trace
  101424
December 26, 2017 18:18 larry@garfieldtech.com (Larry Garfield)
On Tuesday, December 26, 2017 9:56:21 AM CST Sebastian Bergmann wrote:
> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: > > would you mind to explain this? > > "Foo|Bar", "array|string", etc. (still) make no sense to me. > > "scalar" makes sense to me although it is but an alias for > "bool|float|int|string".
If I may, I think the argument has always been that 1) Foo & Bar makes total sense 2) int|float makes total sense 3) int & string is illogical so wouldn't matter anyway 4) Foo|Bar rarely makes sense but may sometimes, and its legality is an acceptable trade-off to get the first two. In previous discussions it always seemed that people fixated on case 4 and ignored the usefulness of cases 1 and 2. --Larry Garfield
  101425
December 26, 2017 18:35 lists@rhsoft.net ("lists@rhsoft.net")
Am 26.12.2017 um 19:18 schrieb Larry Garfield:
> On Tuesday, December 26, 2017 9:56:21 AM CST Sebastian Bergmann wrote: >> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: >>> would you mind to explain this? >> >> "Foo|Bar", "array|string", etc. (still) make no sense to me. >> >> "scalar" makes sense to me although it is but an alias for >> "bool|float|int|string". > > If I may, I think the argument has always been that > > 1) Foo & Bar makes total sense > 2) int|float makes total sense > 3) int & string is illogical so wouldn't matter anyway
not true function x(int|string $x) { $x = (int)$x; } $x can be simply from a database simply because without MYSQLI_OPT_INT_AND_FLOAT_NATIVE which is sadly not default you get everything back as string and so you can place the casting in the function instead of every single caller in strict_types mode while you don#t accept object, array or boolean here why not cast a boolean here? in case of the result of strpos() in the caller is false it likely should not call the function anyways but handle that error itself
> 4) Foo|Bar rarely makes sense but may sometimes, and its legality is an > acceptable trade-off to get the first two. > > In previous discussions it always seemed that people fixated on case 4 and > ignored the usefulness of cases 1 and 2
as this is a programming language it's up to the user who writes the code in the language what is useful for his case - so if one is fixated on 3 or 4 because they would become possible the argumentation is strange anyways and "etc. (still) make no sense to me" is a personal opinion which hardly justifies a downvote at all unless there are real technical reasons in my total valid usecase of 3) above in strict_types mode i must ommit the typehint at all or modify every single caller and that alone would justify unions
  101429
December 27, 2017 09:50 rowan.collins@gmail.com (Rowan Collins)
On 26 December 2017 18:35:29 GMT+00:00, "lists@rhsoft.net" <lists@rhsoft.net> wrote:
> > >Am 26.12.2017 um 19:18 schrieb Larry Garfield: >> If I may, I think the argument has always been that >> >> 1) Foo & Bar makes total sense >> 2) int|float makes total sense >> 3) int & string is illogical so wouldn't matter anyway > >not true > >function x(int|string $x) >{ > $x = (int)$x; >}
I think there's a misunderstanding here. Some previous proposals for "union types" also included "intersection types", so that you could assert "parameter must implement both of these interfaces". So 'Foo|Bar $x' would mean '$x instanceof Foo || $x instanceof Bar' and 'Foo&Bar $x' would mean '$x instanceof Foo && $x instanceof Bar'. I presume that's what Larry means by "int & string is illogical", because it would translate to "is_int($x) && is_string($x)", which is false for all values of $x. This is different from "int | string", which, as you say, might have valid uses. Regards, -- Rowan Collins [IMSoP]
  101430
December 28, 2017 23:21 larry@garfieldtech.com (Larry Garfield)
On Wednesday, December 27, 2017 3:50:54 AM CST Rowan Collins wrote:
> On 26 December 2017 18:35:29 GMT+00:00, "lists@rhsoft.net" <lists@rhsoft.net> wrote:
> >Am 26.12.2017 um 19:18 schrieb Larry Garfield: > >> If I may, I think the argument has always been that > >> > >> 1) Foo & Bar makes total sense > >> 2) int|float makes total sense > >> 3) int & string is illogical so wouldn't matter anyway > > > >not true > > > >function x(int|string $x) > >{ > > > > $x = (int)$x; > > > >} > > I think there's a misunderstanding here. Some previous proposals for "union > types" also included "intersection types", so that you could assert > "parameter must implement both of these interfaces". So 'Foo|Bar $x' would > mean '$x instanceof Foo || $x instanceof Bar' and 'Foo&Bar $x' would mean > '$x instanceof Foo && $x instanceof Bar'. > > I presume that's what Larry means by "int & string is illogical", because it > would translate to "is_int($x) && is_string($x)", which is false for all > values of $x. This is different from "int | string", which, as you say, > might have valid uses. > > Regards,
Correct. Union types I've always seen presented as offering both union and intersection. There are cases where union is great, and where it's kinda silly. There are cases where intersect is great, and where it's kinda silly. Most of the anti- arguments I've seen for "union types" have fixated on "int && string is meaningless, and Foo || Bar is bad design, so union types are bad!" Entirely ignoring the flip side, which is int || string (valid use cases) and Foo && Bar (many many valid use cases). --Larry Garfield
  101431
December 28, 2017 23:59 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 00:21 schrieb Larry Garfield:
> Correct. Union types I've always seen presented as offering both union and > intersection. There are cases where union is great, and where it's kinda > silly. There are cases where intersect is great, and where it's kinda silly. > > Most of the anti- arguments I've seen for "union types" have fixated on "int && > string is meaningless, and Foo || Bar is bad design, so union types are bad!" > Entirely ignoring the flip side, which is int || string (valid use cases) and > Foo && Bar (many many valid use cases)
well, that explains why the same person which hase a usecase for a "scalar" pseudo-type donw-votes https://wiki.php.net/rfc/union_types but it makes his vote not logical at all frankly the only valid reasons to down-vote something should be technical ones which matters for the PHP core itself and not "i don't understand a feature hence nobody should have it"
  101432
December 29, 2017 08:04 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:4b55eed1-8656-ff70-e4e9-ad5e40213405@rhsoft.net...
> > > >Am 29.12.2017 um 00:21 schrieb Larry Garfield: >> Correct. Union types I've always seen presented as offering both union >> and >> intersection. There are cases where union is great, and where it's kinda >> silly. There are cases where intersect is great, and where it's kinda >> silly. >> >> Most of the anti- arguments I've seen for "union types" have fixated on >> "int && >> string is meaningless, and Foo || Bar is bad design, so union types are >> bad!" >> Entirely ignoring the flip side, which is int || string (valid use cases) >> and >> Foo && Bar (many many valid use cases) > >well, that explains why the same person which hase a usecase for a "scalar" >pseudo-type donw-votes https://wiki.php.net/rfc/union_types but it makes >his vote not logical at all > >frankly the only valid reasons to down-vote something should be technical >ones which matters for the PHP core itself and not "i don't understand a >feature hence nobody should have it"
You are missing the point. If an RFC is so badly written that someone does not understand it, or understand what benefits it is supposed to provide, then there is no point in up-voting it. You may contrive a use case where it provides a small benefit, but if that use case is so limited or so obscure that it does not apply to a significant number of developers then that RFC should be voted down simply because it does not provide any significant benefits. -- Tony Marston
  101436
December 29, 2017 13:42 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 09:04 schrieb Tony Marston:
> wrote in message news:4b55eed1-8656-ff70-e4e9-ad5e40213405@rhsoft.net... >> >> Am 29.12.2017 um 00:21 schrieb Larry Garfield: >>> Correct.  Union types I've always seen presented as offering both >>> union and >>> intersection.  There are cases where union is great, and where it's >>> kinda >>> silly.  There are cases where intersect is great, and where it's >>> kinda silly. >>> >>> Most of the anti- arguments I've seen for "union types" have fixated >>> on "int && >>> string is meaningless, and Foo || Bar is bad design, so union types >>> are bad!" >>> Entirely ignoring the flip side, which is int || string (valid use >>> cases) and >>> Foo && Bar (many many valid use cases) >> >> well, that explains why the same person which hase a usecase for a >> "scalar" pseudo-type donw-votes https://wiki.php.net/rfc/union_types >> but it makes his vote not logical at all >> >> frankly the only valid reasons to down-vote something should be >> technical ones which matters for the PHP core itself and not "i don't >> understand a feature hence nobody should have it" > > You are missing the point. If an RFC is so badly written that someone > does not understand it, or understand what benefits it is supposed to > provide, then there is no point in up-voting it
if i don't undrstand it i don't vote at all - that's the point not up not down
  101451
December 30, 2017 09:16 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:f48976dd-589f-e88e-37ba-38096c3a3602@rhsoft.net...
> > > >Am 29.12.2017 um 09:04 schrieb Tony Marston: >> wrote in message news:4b55eed1-8656-ff70-e4e9-ad5e40213405@rhsoft.net... >>> >>> Am 29.12.2017 um 00:21 schrieb Larry Garfield: >>>> Correct. Union types I've always seen presented as offering both union >>>> and >>>> intersection. There are cases where union is great, and where it's >>>> kinda >>>> silly. There are cases where intersect is great, and where it's kinda >>>> silly. >>>> >>>> Most of the anti- arguments I've seen for "union types" have fixated on >>>> "int && >>>> string is meaningless, and Foo || Bar is bad design, so union types are >>>> bad!" >>>> Entirely ignoring the flip side, which is int || string (valid use >>>> cases) and >>>> Foo && Bar (many many valid use cases) >>> >>> well, that explains why the same person which hase a usecase for a >>> "scalar" pseudo-type donw-votes https://wiki.php.net/rfc/union_types but >>> it makes his vote not logical at all >>> >>> frankly the only valid reasons to down-vote something should be >>> technical ones which matters for the PHP core itself and not "i don't >>> understand a feature hence nobody should have it" >> >> You are missing the point. If an RFC is so badly written that someone >> does not understand it, or understand what benefits it is supposed to >> provide, then there is no point in up-voting it > >if i don't undrstand it i don't vote at all - that's the point > >not up >not down
If you can't understand it then you cannot tell what benefit it gives to the greater PHP community, and if you cannot see that it provides any benefit then you should vote it DOWN. Common sense should dictate that you only vote it UP when you are convinced that it will provide something of benefit. If you don't vote at all you are admitting that you are clueless, or don't care, in which case you are not preventing a bad idea from being accepted. If it later turns out that it was a crock of sh*t then you will be partly to blame because you didn't have the intelligence to see it as such and didn't speak up. If you don't understand an RFC then not only do you not understand the benefits that it can provide, you also don't understand the damage that it can cause. -- Tony Marston
  101452
December 30, 2017 09:56 lists@rhsoft.net ("lists@rhsoft.net")
Am 30.12.2017 um 10:16 schrieb Tony Marston:
> wrote in message news:f48976dd-589f-e88e-37ba-38096c3a3602@rhsoft.net... >>> You are missing the point. If an RFC is so badly written that someone >>> does not understand it, or understand what benefits it is supposed to >>> provide, then there is no point in up-voting it >> >> if i don't undrstand it i don't vote at all - that's the point >> >> not up >> not down > > If you can't understand it then you cannot tell what benefit it gives to > the greater PHP community, and if you cannot see that it provides any > benefit then you should vote it DOWN. Common sense should dictate that > you only vote it UP when you are convinced that it will provide > something of benefit. If you don't vote at all you are admitting that > you are clueless, or don't care, in which case you are not preventing a > bad idea from being accepted. If it later turns out that it was a crock > of sh*t then you will be partly to blame because you didn't have the > intelligence to see it as such and didn't speak up. If you don't > understand an RFC then not only do you not understand the benefits that > it can provide, you also don't understand the damage that it can cause.
frankly, in the real world when you don't understand what some people are talking about you don't join and say "no, you are wrong" - you either shut up or ask again but you don't step in yelling "no!"
  101461
December 31, 2017 10:10 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:320cb1b3-222b-2b21-6c39-8d9ea539b267@rhsoft.net...
> > > >Am 30.12.2017 um 10:16 schrieb Tony Marston: >> wrote in message news:f48976dd-589f-e88e-37ba-38096c3a3602@rhsoft.net... >>>> You are missing the point. If an RFC is so badly written that someone >>>> does not understand it, or understand what benefits it is supposed to >>>> provide, then there is no point in up-voting it >>> >>> if i don't undrstand it i don't vote at all - that's the point >>> >>> not up >>> not down >> >> If you can't understand it then you cannot tell what benefit it gives to >> the greater PHP community, and if you cannot see that it provides any >> benefit then you should vote it DOWN. Common sense should dictate that >> you only vote it UP when you are convinced that it will provide something >> of benefit. If you don't vote at all you are admitting that you are >> clueless, or don't care, in which case you are not preventing a bad idea >> from being accepted. If it later turns out that it was a crock of sh*t >> then you will be partly to blame because you didn't have the intelligence >> to see it as such and didn't speak up. If you don't understand an RFC >> then not only do you not understand the benefits that it can provide, you >> also don't understand the damage that it can cause. > >frankly, in the real world when you don't understand what some people are >talking about you don't join and say "no, you are wrong" - you either shut >up or ask again but you don't step in yelling "no!"
It is not about an idea being right or wrong, it is about adding something new to the language. If you are not convinced that it will add value to the language then you should vote it down. Not voting either way because you don't understand the RFC or its proposed benefits just shows that you aren't qualified to vote on anything. -- Tony Marston
  101453
December 30, 2017 10:37 lester@lsces.co.uk (Lester Caine)
On 30/12/17 09:16, Tony Marston wrote:
>>> You are missing the point. If an RFC is so badly written that someone >>> does not understand it, or understand what benefits it is supposed to >>> provide, then there is no point in up-voting it >> >> if i don't undrstand it i don't vote at all - that's the point >> >> not up >> not down > > If you can't understand it then you cannot tell what benefit it gives to > the greater PHP community, and if you cannot see that it provides any > benefit then you should vote it DOWN.
Not being able to vote, many of us have no option to complain about the way things are going. Currently there seems to be several styles of PHP form the nice and simple untyped version I moved to from very strictly typed hard compiled code I'd been using up until then, through to current code which is reliant on third party things like PSR and Composer and expects only strictly typed PHP. The 'greater PHP community' I continue to support is still only looking for a simply life, but each iteration of PHP7 is just making things more and more complex, which is why I STILL have not switched off PHP5 and 5.4 and earlier is still running a large percentage of sites. Just what percentage of the wider community thinks that strict typing is giving an essential benefit? If there was a groundswell for typing then perhaps we would not have this continual debate on just how to jam a little more of a move that way and get on with a version of PHP that is only typed. Then for one can simply avoid it ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  101454
December 30, 2017 14:39 lists@rhsoft.net ("lists@rhsoft.net")
Am 30.12.2017 um 11:37 schrieb Lester Caine:
> On 30/12/17 09:16, Tony Marston wrote: >>>> You are missing the point. If an RFC is so badly written that someone >>>> does not understand it, or understand what benefits it is supposed to >>>> provide, then there is no point in up-voting it >>> >>> if i don't undrstand it i don't vote at all - that's the point >>> >>> not up >>> not down >> >> If you can't understand it then you cannot tell what benefit it gives to >> the greater PHP community, and if you cannot see that it provides any >> benefit then you should vote it DOWN. > > The 'greater PHP community' I continue to support is still only looking > for a simply life, but each iteration of PHP7 is just making things more > and more complex, which is why I STILL have not switched off PHP5 and > 5.4 and earlier is still running a large percentage of sites. Just what > percentage of the wider community thinks that strict typing is giving an > essential benefit? If there was a groundswell for typing then perhaps we > would not have this continual debate on just how to jam a little more of > a move that way and get on with a version of PHP that is only typed. > Then for one can simply avoid it ...
who thinks it don't give you a benefit? for new code it's the best you can do do get it as bugfree as possible and fro old code you still are not forec to any typehints and for migration you have weak types too sorry, but discuss end of 2017 if types was a goof d idea and talk about the 'greater community' but still run PHP5? in the meantime I have changed *everything* written in the last 15 yeas to strict_types=1 and type hints everywhere - you find so much potential bugs that it's worth
  101462
December 31, 2017 10:24 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:28ba9e6a-a3f2-2547-d294-f3a1710d5337@rhsoft.net...
> > > >Am 30.12.2017 um 11:37 schrieb Lester Caine: >> On 30/12/17 09:16, Tony Marston wrote: >>>>> You are missing the point. If an RFC is so badly written that someone >>>>> does not understand it, or understand what benefits it is supposed to >>>>> provide, then there is no point in up-voting it >>>> >>>> if i don't undrstand it i don't vote at all - that's the point >>>> >>>> not up >>>> not down >>> >>> If you can't understand it then you cannot tell what benefit it gives to >>> the greater PHP community, and if you cannot see that it provides any >>> benefit then you should vote it DOWN. >> >> The 'greater PHP community' I continue to support is still only looking >> for a simply life, but each iteration of PHP7 is just making things more >> and more complex, which is why I STILL have not switched off PHP5 and >> 5.4 and earlier is still running a large percentage of sites. Just what >> percentage of the wider community thinks that strict typing is giving an >> essential benefit? If there was a groundswell for typing then perhaps we >> would not have this continual debate on just how to jam a little more of >> a move that way and get on with a version of PHP that is only typed. >> Then for one can simply avoid it ... > >who thinks it don't give you a benefit? > >for new code it's the best you can do do get it as bugfree as possible and >fro old code you still are not forec to any typehints and for migration you >have weak types too > >sorry, but discuss end of 2017 if types was a goof d idea and talk about >the 'greater community' but still run PHP5? in the meantime I have changed >*everything* written in the last 15 yeas to strict_types=1 and type hints >everywhere - you find so much potential bugs that it's worth
Some of us are clever enough to write code that doesn't have those types of bug in the first place. I developed my framework in PHP4 before type hints even existed, and I developed a large enterprise application with that framework which is now being sold to large corporations all over the world. That codebase has moved from PHP 4 through all versions of PHP 5 and is now running on PHP 7.1. During these upgrades I have only changed my code to deal with what has been deprecated, and I have never bothered with any of those new optional extras (such as typehints) unless I have been convinced that the effort of changing my code has measureable benefits. The idea that typehints provide benefits to the whole PHP community is completely bogus. It only provides apparent benefits to those programmers who have moved from a strictly type language to PHP and who feel lost without the crutch that a strongly typed language seems to provide. I work faster with a dynamically and weakly typed language, so speed of development is far more important to me. Any so-called bugs are detected and fixed during the testing phase, so I don't want the language being slowed down performing checks that I don't want. -- Tony Marston
  101464
December 31, 2017 11:06 lester@lsces.co.uk (Lester Caine)
On 31/12/17 10:24, Tony Marston wrote:
> wrote in message news:28ba9e6a-a3f2-2547-d294-f3a1710d5337@rhsoft.net... >> >> >> >> Am 30.12.2017 um 11:37 schrieb Lester Caine: >>> On 30/12/17 09:16, Tony Marston wrote: >>>>>> You are missing the point. If an RFC is so badly written that someone >>>>>> does not understand it, or understand what benefits it is supposed to >>>>>> provide, then there is no point in up-voting it >>>>> >>>>> if i don't undrstand it i don't vote at all - that's the point >>>>> >>>>> not up >>>>> not down >>>> >>>> If you can't understand it then you cannot tell what benefit it >>>> gives to >>>> the greater PHP community, and if you cannot see that it provides any >>>> benefit then you should vote it DOWN. >>> >>> The 'greater PHP community' I continue to support is still only looking >>> for a simply life, but each iteration of PHP7 is just making things more >>> and more complex, which is why I STILL have not switched off PHP5 and >>> 5.4 and earlier is still running a large percentage of sites. Just what >>> percentage of the wider community thinks that strict typing is giving an >>> essential benefit? If there was a groundswell for typing then perhaps we >>> would not have this continual debate on just how to jam a little more of >>> a move that way and get on with a version of PHP that is only typed. >>> Then for one can simply avoid it ... >> >> who thinks it don't give you a benefit? >> >> for new code it's the best you can do do get it as bugfree as possible >> and fro old code you still are not forec to any typehints and for >> migration you have weak types too >> >> sorry, but discuss end of 2017 if types was a goof d idea and talk >> about the 'greater community' but still run PHP5? in the meantime I >> have changed *everything* written in the last 15 yeas to >> strict_types=1 and type hints everywhere - you find so much potential >> bugs that it's worth > > Some of us are clever enough to write code that doesn't have those types > of bug in the first place. I developed my framework in PHP4 before type > hints even existed, and I developed a large enterprise application with > that framework which is now being sold to large corporations all over > the world. That codebase has moved from PHP 4 through all versions of > PHP 5 and is now running on PHP 7.1. During these upgrades I have only > changed my code to deal with what has been deprecated, and I have never > bothered with any of those new optional extras (such as typehints) > unless I have been convinced that the effort of changing my code has > measureable benefits. > > The idea that typehints provide benefits to the whole PHP community is > completely bogus. It only provides apparent benefits to those > programmers who have moved from a strictly type language to PHP and who > feel lost without the crutch that a strongly typed language seems to > provide. I work faster with a dynamically and weakly typed language, so > speed of development is far more important to me.  Any so-called bugs > are detected and fixed during the testing phase, so I don't want the > language being slowed down performing checks that I don't want.
Thanks for that Tony ... almost exactly where I am as well ... I started just as PHP5 came to final betas - from C++ - and never had a problem with the flexibility that provided. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
  101465
December 31, 2017 15:32 lists@rhsoft.net ("lists@rhsoft.net")
Am 31.12.2017 um 11:24 schrieb Tony Marston:
> Some of us are clever enough to write code that doesn't have those types > of bug in the first place. I developed my framework in PHP4 before type > hints even existed, and I developed a large enterprise application with > that framework which is now being sold to large corporations all over > the world. That codebase has moved from PHP 4 through all versions of > PHP 5 and is now running on PHP 7.1. During these upgrades I have only > changed my code to deal with what has been deprecated, and I have never > bothered with any of those new optional extras (such as typehints) > unless I have been convinced that the effort of changing my code has > measureable benefits.
well my codebase dates back to 2002 but is stricted-typed in the meantime - and now?
> The idea that typehints provide benefits to the whole PHP community is > completely bogus. It only provides apparent benefits to those > programmers who have moved from a strictly type language to PHP and who > feel lost without the crutch that a strongly typed language seems to > provide. I work faster with a dynamically and weakly typed language, so > speed of development is far more important to me.  Any so-called bugs > are detected and fixed during the testing phase, so I don't want the > language being slowed down performing checks that I don't want. nosense - after 15 years PHP andmoved everything to strict_types in 2017
(the current year) you can't accuse me that i have recebtly moved from a strongly typed language to PHP and felt lost all the years before you think you work faster because you even don't realize small bugs until they become large enough that you sit there and debug for hours while a type-error with a stacktrace would have shown the mistake at the begin including the root cause
  101468
January 1, 2018 09:12 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:7482b9d4-d487-8c0f-1f92-2e8fef68d2ed@rhsoft.net...
> > > >Am 31.12.2017 um 11:24 schrieb Tony Marston: >> Some of us are clever enough to write code that doesn't have those types >> of bug in the first place. I developed my framework in PHP4 before type >> hints even existed, and I developed a large enterprise application with >> that framework which is now being sold to large corporations all over the >> world. That codebase has moved from PHP 4 through all versions of PHP 5 >> and is now running on PHP 7.1. During these upgrades I have only changed >> my code to deal with what has been deprecated, and I have never bothered >> with any of those new optional extras (such as typehints) unless I have >> been convinced that the effort of changing my code has measureable >> benefits. > >well my codebase dates back to 2002 but is stricted-typed in the meantime - >and now?
PHP was never strictly typed from the start, and I have always loved the flexibility that this provided. I have never felt the urge to use typehints (or type enforcement that it has now become)and any potential bugs that this may create are quickly identified and resolved during my testing.
>> The idea that typehints provide benefits to the whole PHP community is >> completely bogus. It only provides apparent benefits to those programmers >> who have moved from a strictly type language to PHP and who feel lost >> without the crutch that a strongly typed language seems to provide. I >> work faster with a dynamically and weakly typed language, so speed of >> development is far more important to me. Any so-called bugs are detected >> and fixed during the testing phase, so I don't want the language being >> slowed down performing checks that I don't want. > >nosense - after 15 years PHP andmoved everything to strict_types in 2017 >(the current year) you can't accuse me that i have recebtly moved from a >strongly typed language to PHP and felt lost all the years before
Just because a whole load of new features have been added to the language does not mean that I should use them. They are entirely optional, and I choose NOT to use them unless I am convinced that the benefits are worth the effort.
>you think you work faster because you even don't realize small bugs until >they become large enough that you sit there and debug for hours while a >type-error with a stacktrace would have shown the mistake at the begin >including the root cause
As I said previously, any such errors that may be caused by not using a strictly typed language are detected and fixed when I test my code. My main application has been in live use since 2008, and you can count on one hand the number of bugs which are reported each year. -- Tony Marston
  101459
December 30, 2017 21:55 tendoaki@gmail.com (Michael Morris)
On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote:

> > Not being able to vote, many of us have no option to complain about the > way things are going. Currently there seems to be several styles of PHP > form the nice and simple untyped version I moved to from very strictly > typed hard compiled code I'd been using up until then, through to > current code which is reliant on third party things like PSR and > Composer and expects only strictly typed PHP. > >
This is born of the fact that while ignoring datatype makes learning PHP easier, it makes using it harder - especially when testing. Mark me as against union types. First, it places the burden of getting the type right on the calling programmer. Stock PHP code doesn't do this and if popular 3rd party libraries start doing this too much it makes the language harder to learn. Second it blocks this proposal, which is a way to give people who want to control types the ability to do so in their own code without creating BC breaks in PHP or interoperability problems with other libraries. Doing this requires declaring variable types as an OPTION. The default type of a variable will be scalar. Under what I propose putting what is now a type hint on the function line will become a type declaration, and a casting operation will result if the wrong type is passed in. So function foo( int $a ) {} Obviously this path becomes unavailable to us with union types - and by comparison union types is an ineffective band-aid. The above is a shorthand for this function foo ( $arg ) { var int $a = $arg; } When a variable is declared this way it will autocast any assignment to the declared type. The only way to get around this is redeclare the type. Now some might be wondering, why not use this shorter statement: int $a = 3; The reason is this - I propose that syntax will lock the type down, but it won't autocast assignments - it iwll instead throw a TypeError if the assignment type doesn't match. Anyway, there is one BC break - see it? function foo( int $a ) { $a = 'hi'; } Currently $a becomes a string of 'hi'. Under this proposal $a remains an it and it is assigned the cast result of 'hi', which I believe is 0. Since the format is relatively new - PHP 7 - changing it in 8 won't be as disruptive as something that's been around a long time. Also, changing a var type deliberately after declaring it is a bad practice, further reducing the scope of code affected, but it's certainly not 0, so this is PHP 8.0 minimum. Now next, class instance creation. SomeClass $a = new SomeClass(); Doing this locks $a to SomeClass, and trying to assign it to something else will trip a type error. var SomeClass $a = new SomeClass(); Since there's no way to cast arbitrary arguments to SomeClass I'm not sure how this should be handled. Within classes.. class SomeClass { public $a = null; // Creates a scalar. public var int $b = 3; // Creates an autocasting int protected int $c = 5; // Creates an int. Errors will pitch on bad assign. protected OtherClass $b; } This syntax locks down, or *really* locks down types, but it's entirely opt-in. If we're going to go down the road of sticter types this has to be done. It's also an example of why pasting in functionality without an over-arching plan is a bad idea. If Union types is included part of this solution will be forever lost since it's likely incompatible with union types (or at least union types with scalars - union types with objects wouldn't be affected).
  101460
December 30, 2017 22:14 lists@rhsoft.net ("lists@rhsoft.net")
Am 30.12.2017 um 22:55 schrieb Michael Morris:
> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote: > >> >> Not being able to vote, many of us have no option to complain about the >> way things are going. Currently there seems to be several styles of PHP >> form the nice and simple untyped version I moved to from very strictly >> typed hard compiled code I'd been using up until then, through to >> current code which is reliant on third party things like PSR and >> Composer and expects only strictly typed PHP. > > This is born of the fact that while ignoring datatype makes learning PHP > easier, it makes using it harder - especially when testing.
and using type hints is completly opt-in at all
> Mark me as against union types. First, it places the burden of getting the > type right on the calling programmer. Stock PHP code doesn't do this and if > popular 3rd party libraries start doing this too much it makes the language > harder to learn.
but the outcome is way cleaner because errors are not silently as it is now without using type-hints - anyways, you are not forced to use any type hints at all but the people which know how bad code works without care about are able to do so and without unnions that all is very limited
> Second it blocks this proposal, which is a way to give people who want to > control types the ability to do so in their own code without creating BC > breaks in PHP or interoperability problems with other libraries. Doing this > requires declaring variable types as an OPTION. The default type of a > variable will be scalar.
that is not true - even if the syntax would be BC compatible the behavior won#t
> Under what I propose putting what is now a type hint on the function line > will become a type declaration, and a casting operation will result if the > wrong type is passed in. So > > function foo( int $a ) {} > > Obviously this path becomes unavailable to us with union types - and by > comparison union types is an ineffective band-aid. The above is a shorthand > for this > > function foo ( $arg ) { > var int $a = $arg; > } > > When a variable is declared this way it will autocast any assignment to the > declared type. The only way to get around this is redeclare the type
this is hard to optimize - just look at the optimizations of PHP 7.1 also this ship has sailed long ago as we now have type hints (and i did not understand at all why they where intoruced in 5.3 only for arrays and objects) the point of union types is that you are not limited to "int or float or string" but can say "int or string both are OK, i hanlde that in my code" and so you can use strict_types with GET/POST or database results which are by defintion string but don't accept objects or arrays you can't handle proper function test(int|string $x) { $x = (int)$x; } currently without type-hints you have a "array to string conversion" insead fail and fix that at the caller where *obvisouly* nobody did realize that any random var froma request could be any array this has to be checked *before* call a function with such invalid data
  101463
December 31, 2017 10:27 TonyMarston@hotmail.com ("Tony Marston")
"Michael Morris"  wrote in message 
news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com...
> >On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote: > >> >> Not being able to vote, many of us have no option to complain about the >> way things are going. Currently there seems to be several styles of PHP >> form the nice and simple untyped version I moved to from very strictly >> typed hard compiled code I'd been using up until then, through to >> current code which is reliant on third party things like PSR and >> Composer and expects only strictly typed PHP. >> >> > >This is born of the fact that while ignoring datatype makes learning PHP >easier, it makes using it harder - especially when testing.
I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whasoever. Does it make testing more difficult? No, it does not. -- Tony Marston
  101466
December 31, 2017 15:33 lists@rhsoft.net ("lists@rhsoft.net")
Am 31.12.2017 um 11:27 schrieb Tony Marston:
> "Michael Morris"  wrote in message > news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com... >> >> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote: >> >>> >>> Not being able to vote, many of us have no option to complain about the >>> way things are going. Currently there seems to be several styles of PHP >>> form the nice and simple untyped version I moved to from very strictly >>> typed hard compiled code I'd been using up until then, through to >>> current code which is reliant on third party things like PSR and >>> Composer and expects only strictly typed PHP. >> >> This is born of the fact that while ignoring datatype makes learning PHP >> easier, it makes using it harder - especially when testing. > > I strongly disagree. I have been using PHP since 2001 and I have never > used type hinting in any form whasoever. Does it make testing more > difficult? No, it does not
"I have never used type hinting in any form whasoever" - so how can you be qualified at all to tell anything about the difference how it would be if you would have used it?
  101467
December 31, 2017 19:16 mdwheele@ncsu.edu (Dustin Wheeler)
> > On Dec 31, 2017, at 10:33 AM, "lists@rhsoft.net" <lists@rhsoft.net> wrote: > > > >> Am 31.12.2017 um 11:27 schrieb Tony Marston: >> "Michael Morris" wrote in message news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com... >>> >>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> wrote: >>>> >>>> >>>> Not being able to vote, many of us have no option to complain about the >>>> way things are going. Currently there seems to be several styles of PHP >>>> form the nice and simple untyped version I moved to from very strictly >>>> typed hard compiled code I'd been using up until then, through to >>>> current code which is reliant on third party things like PSR and >>>> Composer and expects only strictly typed PHP. >>> >>> This is born of the fact that while ignoring datatype makes learning PHP >>> easier, it makes using it harder - especially when testing. >> I strongly disagree. I have been using PHP since 2001 and I have never used type hinting in any form whasoever. Does it make testing more difficult? No, it does not > > "I have never used type hinting in any form whasoever" - so how can you be qualified at all to tell anything about the difference how it would be if you would have used it?
Could the discussion be re-centered around the RFC at-hand rather than measuring "ego"? It seems that any thread that has both rhsoft and Tony involved devolves into a competition of opinion without much attempt to meet in the middle or understand one another. Thanks.
  101470
January 1, 2018 09:21 TonyMarston@hotmail.com ("Tony Marston")
"Dustin Wheeler"  wrote in message 
news:A93010E9-7E52-4144-81B8-6FB6F47D85FF@ncsu.edu...
> >> >> On Dec 31, 2017, at 10:33 AM, "lists@rhsoft.net" <lists@rhsoft.net> >> wrote: >> >> >> >>> Am 31.12.2017 um 11:27 schrieb Tony Marston: >>> "Michael Morris" wrote in message >>> news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com... >>>> >>>>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> >>>>> wrote: >>>>> >>>>> >>>>> Not being able to vote, many of us have no option to complain about >>>>> the >>>>> way things are going. Currently there seems to be several styles of >>>>> PHP >>>>> form the nice and simple untyped version I moved to from very strictly >>>>> typed hard compiled code I'd been using up until then, through to >>>>> current code which is reliant on third party things like PSR and >>>>> Composer and expects only strictly typed PHP. >>>> >>>> This is born of the fact that while ignoring datatype makes learning >>>> PHP >>>> easier, it makes using it harder - especially when testing. >>> I strongly disagree. I have been using PHP since 2001 and I have never >>> used type hinting in any form whasoever. Does it make testing more >>> difficult? No, it does not >> >> "I have never used type hinting in any form whasoever" - so how can you >> be qualified at all to tell anything about the difference how it would be >> if you would have used it? > >Could the discussion be re-centered around the RFC at-hand rather than >measuring "ego"? It seems that any thread that has both rhsoft and Tony >involved devolves into a competition of opinion without much attempt to >meet in the middle or understand one another. > >Thanks. =
Any attempt to make typehinting (or type enforcement as it has now become) is simply adding complications to the language which do not provide benefits to the greater PHP community, just a minority of poor coders who want the language to trap the bugs that they create in their code. There are some of us out there who are capable of writing bug-free code without type enforcement, so this RFC (and anything else connected with type hinting/enforcement) is something we don't need to use, therefore it has no benefits for us. -- Tony Marston
  101473
January 1, 2018 11:52 lists@rhsoft.net ("lists@rhsoft.net")
Am 01.01.2018 um 10:21 schrieb Tony Marston:
> Any attempt to make typehinting (or type enforcement as it has now > become) is simply adding complications to the language which do not > provide benefits to the greater PHP community, just a minority of poor > coders who want the language to trap the bugs that they create in their > code. There are some of us out there who are capable of writing bug-free > code without type enforcement, so this RFC (and anything else connected > with type hinting/enforcement) is something we don't need to use, > therefore it has no benefits for us.
breaking news: nobody is enforces anything to you just don't use features you don't want to use but fix your dirty attitude that everything you don't need should be voted down! "There are some of us out there who are capable of writing bug-free code" is a laughable argumentation anyways
  101474
January 2, 2018 08:28 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:96908b43-e2b3-923a-5452-903f26838e7b@rhsoft.net...
> > > >Am 01.01.2018 um 10:21 schrieb Tony Marston: >> Any attempt to make typehinting (or type enforcement as it has now >> become) is simply adding complications to the language which do not >> provide benefits to the greater PHP community, just a minority of poor >> coders who want the language to trap the bugs that they create in their >> code. There are some of us out there who are capable of writing bug-free >> code without type enforcement, so this RFC (and anything else connected >> with type hinting/enforcement) is something we don't need to use, >> therefore it has no benefits for us. > >breaking news: >nobody is enforces anything to you > >just don't use features you don't want to use but fix your dirty attitude >that everything you don't need should be voted down!
I never said that just because I personally won't use a proposed feature that it should be voted down. It should only be voted up if it can provide benefits to the greater PHP community and not just a few individuals. I specifically said that if you don't understand an RFC or the benefits that it is supposed to provide then you should vote it down, otherwise you could be held responsible for allowing the language to be corrupted.
>"There are some of us out there who are capable of writing bug-free code" >is a laughable argumentation anyways
Why is that laughable? You appear to want to make the language more complicated just to catch the bugs that you keep creating. Some of us have learned how not to write such buggy code in the first place. -- Tony Marston
  101475
January 2, 2018 08:35 ocramius@gmail.com (Marco Pivetta)
On Tue, Jan 2, 2018 at 9:28 AM, Tony Marston <TonyMarston@hotmail.com>
wrote:

> "There are some of us out there who are capable of writing bug-free code" >> is a laughable argumentation anyways >> > > Why is that laughable? You appear to want to make the language more > complicated just to catch the bugs that you keep creating. Some of us have > learned how not to write such buggy code in the first place.
Please do stop spewing bullshit: some people still want to read meaningful things in this mailing list. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
  101469
January 1, 2018 09:15 TonyMarston@hotmail.com ("Tony Marston")
wrote in message news:e425ecf3-4ef8-826d-bf4c-3c7b588e1c1f@rhsoft.net...
> > > >Am 31.12.2017 um 11:27 schrieb Tony Marston: >> "Michael Morris" wrote in message >> news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com... >>> >>> On Sat, Dec 30, 2017 at 5:37 AM, Lester Caine <lester@lsces.co.uk> >>> wrote: >>> >>>> >>>> Not being able to vote, many of us have no option to complain about the >>>> way things are going. Currently there seems to be several styles of PHP >>>> form the nice and simple untyped version I moved to from very strictly >>>> typed hard compiled code I'd been using up until then, through to >>>> current code which is reliant on third party things like PSR and >>>> Composer and expects only strictly typed PHP. >>> >>> This is born of the fact that while ignoring datatype makes learning PHP >>> easier, it makes using it harder - especially when testing. >> >> I strongly disagree. I have been using PHP since 2001 and I have never >> used type hinting in any form whasoever. Does it make testing more >> difficult? No, it does not > >"I have never used type hinting in any form whasoever" - so how can you be >qualified at all to tell anything about the difference how it would be if >you would have used it?
I know that it would take a HUGE amount of effort to go through my massive code base to put typehints on every function and method, but for what benefit? Unless I can measure a definite performance gain then the lack of benefits would not justify the cost. -- Tony Marston
  101433
December 29, 2017 12:08 php@fleshgrinder.com (Fleshgrinder)
On 12/29/2017 12:21 AM, Larry Garfield wrote:
> On Wednesday, December 27, 2017 3:50:54 AM CST Rowan Collins wrote: >> On 26 December 2017 18:35:29 GMT+00:00, "lists@rhsoft.net" > <lists@rhsoft.net> wrote: >>> Am 26.12.2017 um 19:18 schrieb Larry Garfield: >>>> If I may, I think the argument has always been that >>>> >>>> 1) Foo & Bar makes total sense >>>> 2) int|float makes total sense >>>> 3) int & string is illogical so wouldn't matter anyway >>> >>> not true >>> >>> function x(int|string $x) >>> { >>> >>> $x = (int)$x; >>> >>> } >> >> I think there's a misunderstanding here. Some previous proposals for "union >> types" also included "intersection types", so that you could assert >> "parameter must implement both of these interfaces". So 'Foo|Bar $x' would >> mean '$x instanceof Foo || $x instanceof Bar' and 'Foo&Bar $x' would mean >> '$x instanceof Foo && $x instanceof Bar'. >> >> I presume that's what Larry means by "int & string is illogical", because it >> would translate to "is_int($x) && is_string($x)", which is false for all >> values of $x. This is different from "int | string", which, as you say, >> might have valid uses. >> >> Regards, > > Correct. Union types I've always seen presented as offering both union and > intersection. There are cases where union is great, and where it's kinda > silly. There are cases where intersect is great, and where it's kinda silly. > > Most of the anti- arguments I've seen for "union types" have fixated on "int && > string is meaningless, and Foo || Bar is bad design, so union types are bad!" > Entirely ignoring the flip side, which is int || string (valid use cases) and > Foo && Bar (many many valid use cases). > > --Larry Garfield >
What is the use case for `int|float`? I mean, if f is able to process a `float` than f is able to process an `int` and since `int` is already automatically changed to a `float`, well, you're done. The only situation (I can think of) where this might make a difference is while formatting them. However, in those cases one usually wants to accept many more types (or better yet, let the type format itself). I think that the union RFC was missing proper rules for disjunction (and conjunction if intersection were to be included) as well as information on disjointness. The latter would be important for exhaustive switches that are enforced by the runtime (we'd probably need new keywords here, e.g. `match` + `is`). -- Richard "Fleshgrinder" Fussenegger
  101434
December 29, 2017 12:26 rowan.collins@gmail.com (Rowan Collins)
On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder <php@fleshgrinder.com> wrote:
>What is the use case for `int|float`? I mean, if f is able to process a >`float` than f is able to process an `int` and since `int` is already >automatically changed to a `float`, well, you're done.
I think it is somewhat tedious if we discuss every possible pair of types, just as it would be somewhat messy if we added a new keyword for every combination we found a use case for. The beauty of a general-purpose syntax is precisely that a user can use whatever combination they need, and not use combinations they don't need. I'm sure there are plenty of nonsensical or redundant checks that can be expressed in other parts of the language, but that doesn't mean those language constructs are useless or damaging. Regards, -- Rowan Collins [IMSoP]
  101435
December 29, 2017 12:56 php@fleshgrinder.com (Fleshgrinder)
On 12/29/2017 1:26 PM, Rowan Collins wrote:
> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder > <php@fleshgrinder.com> wrote: >> What is the use case for `int|float`? I mean, if f is able to >> process a `float` than f is able to process an `int` and since >> `int` is already automatically changed to a `float`, well, you're >> done. > > I think it is somewhat tedious if we discuss every possible pair of > types, just as it would be somewhat messy if we added a new keyword > for every combination we found a use case for. The beauty of a > general-purpose syntax is precisely that a user can use whatever > combination they need, and not use combinations they don't need. I'm > sure there are plenty of nonsensical or redundant checks that can be > expressed in other parts of the language, but that doesn't mean those > language constructs are useless or damaging. > > Regards, >
I agree and I do not intend to do so, I actually am not even questioning the usefulness of union and intersection types. I am more curious in regards to providing a `number` type. Seems useless to me. -- Richard "Fleshgrinder" Fussenegger
  101437
December 29, 2017 14:20 php-lists@koalephant.com (Stephen Reay)
> On 29 Dec 2017, at 19:56, Fleshgrinder <php@fleshgrinder.com> wrote: > >> On 12/29/2017 1:26 PM, Rowan Collins wrote: >> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder >> <php@fleshgrinder.com> wrote: >>> What is the use case for `int|float`? I mean, if f is able to >>> process a `float` than f is able to process an `int` and since >>> `int` is already automatically changed to a `float`, well, you're >>> done. >> >> I think it is somewhat tedious if we discuss every possible pair of >> types, just as it would be somewhat messy if we added a new keyword >> for every combination we found a use case for. The beauty of a >> general-purpose syntax is precisely that a user can use whatever >> combination they need, and not use combinations they don't need. I'm >> sure there are plenty of nonsensical or redundant checks that can be >> expressed in other parts of the language, but that doesn't mean those >> language constructs are useless or damaging. >> >> Regards, >> > > I agree and I do not intend to do so, I actually am not even questioning > the usefulness of union and intersection types. I am more curious in > regards to providing a `number` type. Seems useless to me. > > -- > Richard "Fleshgrinder" Fussenegger > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I'm not sure "number" as a predefined type union is necessary but int|float would allow a method to accept either in strict mode, and as you said it would also be useful for eg a formatting function.
  101438
December 29, 2017 15:04 larry@garfieldtech.com (Larry Garfield)
On Friday, December 29, 2017 8:20:14 AM CST Stephen Reay wrote:
> > On 29 Dec 2017, at 19:56, Fleshgrinder <php@fleshgrinder.com> wrote: > >> On 12/29/2017 1:26 PM, Rowan Collins wrote: > >> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder > >> > >> <php@fleshgrinder.com> wrote: > >>> What is the use case for `int|float`? I mean, if f is able to > >>> process a `float` than f is able to process an `int` and since > >>> `int` is already automatically changed to a `float`, well, you're > >>> done. > >> > >> I think it is somewhat tedious if we discuss every possible pair of > >> types, just as it would be somewhat messy if we added a new keyword > >> for every combination we found a use case for. The beauty of a > >> general-purpose syntax is precisely that a user can use whatever > >> combination they need, and not use combinations they don't need. I'm > >> sure there are plenty of nonsensical or redundant checks that can be > >> expressed in other parts of the language, but that doesn't mean those > >> language constructs are useless or damaging. > >> > >> Regards, > > > > I agree and I do not intend to do so, I actually am not even questioning > > the usefulness of union and intersection types. I am more curious in > > regards to providing a `number` type. Seems useless to me. > > I'm not sure "number" as a predefined type union is necessary but int|float > would allow a method to accept either in strict mode, and as you said it > would also be useful for eg a formatting function.
I think he's referring more to the fact that int -> float is the only auto-cast allowed in strict mode, so it's not a great example of where a scalar union type would be useful. Which is a fair point. Nonetheless, it sounds like we're all saying the same thing: The fact that there are cases where a union or intersection declaration would be nonsensical or arguably poor design doesn't change the fact that there are plenty of cases where they would be entirely sensible and very good design, and building a bunch of one-off custom unions (scalar, number, mixed, iterable, etc.) is a poor substitute. So to those who voted against allowing Foo && Bar as a declaration, why? More specifically, what would get you to change your vote to allow general union/ intersection types, so we don't need all of these one-offs? --Larry Garfield
  101439
December 29, 2017 15:09 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 13:08 schrieb Fleshgrinder:
> What is the use case for `int|float`? I mean, if f is able to process a > `float` than f is able to process an `int` and since `int` is already > automatically changed to a `float`, well, you're done
just read the mass of bugreports caused by float answered with the default paragraph below and you know why you don't want your int-values silently converted to a float 7 may become to 7.000000000000000001 or something similar and "$x === 7" may also fail wile the argument was int 7 ________________________ Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. If you would like to know more about "floats" and what IEEE 754 is, read this: http://www.floating-point-gui.de/
  101443
December 29, 2017 17:18 php@fleshgrinder.com (Fleshgrinder)
On 12/29/2017 4:09 PM, lists@rhsoft.net wrote:
> > Am 29.12.2017 um 13:08 schrieb Fleshgrinder: >> What is the use case for `int|float`? I mean, if f is able to process a >> `float` than f is able to process an `int` and since `int` is already >> automatically changed to a `float`, well, you're done > > just read the mass of bugreports caused by float answered with the > default paragraph below and you know why you don't want your int-values > silently converted to a float > > 7 may become to 7.000000000000000001 or something similar and "$x === 7" > may also fail wile the argument was int 7 > ________________________ > > Floating point values have a limited precision. Hence a value might > not have the same string representation after any processing. That also > includes writing a floating point value in your script and directly > printing it without any mathematical operations. > > If you would like to know more about "floats" and what IEEE > 754 is, read this: > http://www.floating-point-gui.de/ >
Obviously but this does not answer anything. You expect an int or a float, hence, you need to be prepared to handle floats. Your 7 example is the best illustration. You need to handle those situations in your script with the appropriate strategy for your domain (rounding, truncation, floor, ...). -- Richard "Fleshgrinder" Fussenegger
  101444
December 29, 2017 17:21 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 18:18 schrieb Fleshgrinder:
> On 12/29/2017 4:09 PM, lists@rhsoft.net wrote: >> >> Am 29.12.2017 um 13:08 schrieb Fleshgrinder: >>> What is the use case for `int|float`? I mean, if f is able to process a >>> `float` than f is able to process an `int` and since `int` is already >>> automatically changed to a `float`, well, you're done >> >> just read the mass of bugreports caused by float answered with the >> default paragraph below and you know why you don't want your int-values >> silently converted to a float >> >> 7 may become to 7.000000000000000001 or something similar and "$x === 7" >> may also fail wile the argument was int 7 >> ________________________ >> >> Floating point values have a limited precision. Hence a value might >> not have the same string representation after any processing. That also >> includes writing a floating point value in your script and directly >> printing it without any mathematical operations. >> >> If you would like to know more about "floats" and what IEEE >> 754 is, read this: >> http://www.floating-point-gui.de/ > > Obviously but this does not answer anything. You expect an int or a > float, hence, you need to be prepared to handle floats. Your 7 example > is the best illustration. You need to handle those situations in your > script with the appropriate strategy for your domain (rounding, > truncation, floor, ...)
no, when i accept "int|float" i don't get something converted at all and i can handle the cases different - when it#s silently casted to a float i have no way to know it was a int at call time
  101446
December 29, 2017 17:24 php@fleshgrinder.com (Fleshgrinder)
On 12/29/2017 6:21 PM, lists@rhsoft.net wrote:
> no, when i accept "int|float" i don't get something converted at all and > i can handle the cases different - when it#s silently casted to a float > i have no way to know it was a int at call time >
Again, obviously, the question remains, why would you care? Please provide convincing arguments as this would become the body of the corresponding RFC. Adding that type is super simple, the question is why is it so super handy? PS: Despite union and intersection types, they automatically allow this form and I repeat that I am totally in favor of them. The question is truly about `number` only which would accept `int` and `float` (no `string`). -- Richard "Fleshgrinder" Fussenegger
  101448
December 29, 2017 17:30 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 18:24 schrieb Fleshgrinder:
> On 12/29/2017 6:21 PM, lists@rhsoft.net wrote: >> no, when i accept "int|float" i don't get something converted at all and >> i can handle the cases different - when it#s silently casted to a float >> i have no way to know it was a int at call time >> > > Again, obviously, the question remains, why would you care? Please > provide convincing arguments as this would become the body of the > corresponding RFC. Adding that type is super simple, the question is why > is it so super handy?
beause i can insert the value to a int field of a database without additional costs, because i can write faster code-paths dealing with integers which don't have all the magic problems of floats and so on
> PS: Despite union and intersection types, they automatically allow this > form and I repeat that I am totally in favor of them. The question is > truly about `number` only which would accept `int` and `float` (no > `string`)
nobody needs "number" - the problem is that people downvoted the union RFC for no good reasons and "i don't see a benefit, i don't like it" are no valid reasons to do so - and to the other guy which asked why someone should up-vote for something he don't understand - nobody says that - i didn't know that voting for each and any RFC is mandatory - so just ignore it when you don#t care instead downvote
  101456
December 30, 2017 17:15 sebastian@php.net (Sebastian Bergmann)
Am 29.12.2017 um 18:30 schrieb lists@rhsoft.net:
> "i don't see a benefit, i don't like it" are no valid reasons to do so
I strongly disagree. If a majority of people do not see the benefit of a syntax change then the syntax should not be changed. A change to the syntax of PHP has a ripple effect throughout the library and tools ecosystem of PHP. This is a cost. This cost needs to be justified by a benefit.
  101458
December 30, 2017 17:23 lists@rhsoft.net ("lists@rhsoft.net")
Am 30.12.2017 um 18:15 schrieb Sebastian Bergmann:
> Am 29.12.2017 um 18:30 schrieb lists@rhsoft.net: >> "i don't see a benefit, i don't like it" are no valid reasons to do so > > I strongly disagree. If a majority of people do not see the benefit of a > syntax change then the syntax should not be changed. A change to the > syntax of PHP has a ripple effect throughout the library and tools > ecosystem of PHP. This is a cost. This cost needs to be justified by a > benefit.
which costs do a new feature without BC break have for the ecosystem?
  101450
December 29, 2017 18:34 php-lists@koalephant.com (Stephen Reay)
> On 30 Dec 2017, at 00:24, Fleshgrinder <php@fleshgrinder.com> wrote: > > Again, obviously, the question remains, why would you care?
Really, that's what's obvious to you? What's obvious to *me* is that if a method accepts two different types of parameters, you'd want to know which was passed in.
  101440
December 29, 2017 15:37 nikita.ppv@gmail.com (Nikita Popov)
On Fri, Dec 29, 2017 at 1:08 PM, Fleshgrinder <php@fleshgrinder.com> wrote:

> On 12/29/2017 12:21 AM, Larry Garfield wrote: > > On Wednesday, December 27, 2017 3:50:54 AM CST Rowan Collins wrote: > >> On 26 December 2017 18:35:29 GMT+00:00, "lists@rhsoft.net" > > <lists@rhsoft.net> wrote: > >>> Am 26.12.2017 um 19:18 schrieb Larry Garfield: > >>>> If I may, I think the argument has always been that > >>>> > >>>> 1) Foo & Bar makes total sense > >>>> 2) int|float makes total sense > >>>> 3) int & string is illogical so wouldn't matter anyway > >>> > >>> not true > >>> > >>> function x(int|string $x) > >>> { > >>> > >>> $x = (int)$x; > >>> > >>> } > >> > >> I think there's a misunderstanding here. Some previous proposals for > "union > >> types" also included "intersection types", so that you could assert > >> "parameter must implement both of these interfaces". So 'Foo|Bar $x' > would > >> mean '$x instanceof Foo || $x instanceof Bar' and 'Foo&Bar $x' would > mean > >> '$x instanceof Foo && $x instanceof Bar'. > >> > >> I presume that's what Larry means by "int & string is illogical", > because it > >> would translate to "is_int($x) && is_string($x)", which is false for all > >> values of $x. This is different from "int | string", which, as you say, > >> might have valid uses. > >> > >> Regards, > > > > Correct. Union types I've always seen presented as offering both union > and > > intersection. There are cases where union is great, and where it's kinda > > silly. There are cases where intersect is great, and where it's kinda > silly. > > > > Most of the anti- arguments I've seen for "union types" have fixated on > "int && > > string is meaningless, and Foo || Bar is bad design, so union types are > bad!" > > Entirely ignoring the flip side, which is int || string (valid use > cases) and > > Foo && Bar (many many valid use cases). > > > > --Larry Garfield > > > > What is the use case for `int|float`? I mean, if f is able to process a > `float` than f is able to process an `int` and since `int` is already > automatically changed to a `float`, well, you're done. > > The only situation (I can think of) where this might make a difference > is while formatting them. However, in those cases one usually wants to > accept many more types (or better yet, let the type format itself). > > I think that the union RFC was missing proper rules for disjunction (and > conjunction if intersection were to be included) as well as information > on disjointness. The latter would be important for exhaustive switches > that are enforced by the runtime (we'd probably need new keywords here, > e.g. `match` + `is`). >
int|float is the natural type of numeric operations in PHP. Integers automatically overflow into floating point numbers, so signatures using int in conjunction with numeric operations are somewhat problematic. Having an explicit number type also goes well with an explicit number cast. PHP internally has a notion of a number cast (which is the basis for arithmetic operations), but currently does not expose it. As such, number casts currently have to be simulated using workarounds like +$x. Regarding the union type RFCs, from what I remember, one of my personal issues with it were the complex rules involving scalar type unions in weak typing mode. It's non-trivial to decide what a value should be casted to if it does not have the correct type. It's sort of clear what "1.5" passed to an int|float union becomes, but it's not intuitively obvious what should happen if you pass "foo" to a bool|int union, etc. Regards, Nikita
  101441
December 29, 2017 15:43 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 16:37 schrieb Nikita Popov:
> Regarding the union type RFCs, from what I remember, one of my personal > issues with it were the complex rules involving scalar type unions in weak > typing mode. It's non-trivial to decide what a value should be casted to if > it does not have the correct type. It's sort of clear what "1.5" passed to > an int|float union becomes, but it's not intuitively obvious what should > happen if you pass "foo" to a bool|int union, etc.
in case of "bool|int" cast it to bool in case of "int|bool" cast it to int first comes, first serve
  101442
December 29, 2017 17:13 php@fleshgrinder.com (Fleshgrinder)
On 12/29/2017 4:37 PM, Nikita Popov wrote:
> int|float is the natural type of numeric operations in PHP. Integers > automatically overflow into floating point numbers, so signatures using int > in conjunction with numeric operations are somewhat problematic. > > Having an explicit number type also goes well with an explicit number cast. > PHP internally has a notion of a number cast (which is the basis for > arithmetic operations), but currently does not expose it. As such, number > casts currently have to be simulated using workarounds like +$x. >
Not sure I fully understand what you are saying. I mean, the accuracy problem will prevail no matter what because at some point we have to change that long to a double. The earlier the better so users know what they are dealing with. `+$x` seems like something that is only of interest if my source is a string and I don't know if it should be int or float. This on the other hand sounds like something that is happening at the edges of the application. Or maybe you had something else in mind? On 12/29/2017 4:37 PM, Nikita Popov wrote:
> Regarding the union type RFCs, from what I remember, one of my personal > issues with it were the complex rules involving scalar type unions in weak > typing mode. It's non-trivial to decide what a value should be casted to if > it does not have the correct type. It's sort of clear what "1.5" passed to > an int|float union becomes, but it's not intuitively obvious what should > happen if you pass "foo" to a bool|int union, etc. >
Why exactly is it necessary to support weak mode together with unions and intersections? It is obviously unclear in many situations what should happen, so why not simply bail like in strict mode? I mean, strict mode was added for backwards compatibility reasons. This is a new future, there is no backwards compatibility. Anyone using it shall abide to the strict rules of it. -- Richard "Fleshgrinder" Fussenegger
  101445
December 29, 2017 17:23 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 18:13 schrieb Fleshgrinder:
> Why exactly is it necessary to support weak mode together with unions > and intersections? It is obviously unclear in many situations what > should happen, so why not simply bail like in strict mode?
is also a good enough way to handle it now as we have the problem that a type-hinted param don't accept NULL and cast it to 0 anyways even in weak mode
  101455
December 30, 2017 15:13 cmbecker69@gmx.de ("Christoph M. Becker")
On 29.12.2017 at 16:37, Nikita Popov wrote:

> On Fri, Dec 29, 2017 at 1:08 PM, Fleshgrinder <php@fleshgrinder.com> wrote: > >> What is the use case for `int|float`? I mean, if f is able to process a >> `float` than f is able to process an `int` and since `int` is already >> automatically changed to a `float`, well, you're done. > > int|float is the natural type of numeric operations in PHP. Integers > automatically overflow into floating point numbers, so signatures using int > in conjunction with numeric operations are somewhat problematic.
In my humble opinion, introducing `int|float` or `number` types would not solve the real problem, namely that overflowing to float easily causes unexpected behavior. For instance: PHP_INT_MAX + 1 > PHP_INT_MAX // => false (64bit arch) -- Christoph M. Becker
  101457
December 30, 2017 17:16 sebastian@php.net (Sebastian Bergmann)
Am 29.12.2017 um 16:37 schrieb Nikita Popov:
> Having an explicit number type also goes well with an explicit number cast. > PHP internally has a notion of a number cast (which is the basis for > arithmetic operations), but currently does not expose it. As such, number > casts currently have to be simulated using workarounds like +$x.
PHP also already has is_numeric().
  101426
December 26, 2017 19:15 pollita@php.net (Sara Golemon)
On Tue, Dec 26, 2017 at 10:56 AM, Sebastian Bergmann <sebastian@php.net> wrote:
> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: >> would you mind to explain this? > > "Foo|Bar", "array|string", etc. (still) make no sense to me. > > "scalar" makes sense to me although it is but an alias for > "bool|float|int|string". > Would you feel differently if we combined union types with type aliasing?
use Numeric = int | float; function foo(Numeric $bar) { ... } -Sara
  101428
December 26, 2017 22:50 lists@rhsoft.net ("lists@rhsoft.net")
Am 26.12.2017 um 20:15 schrieb Sara Golemon:
> On Tue, Dec 26, 2017 at 10:56 AM, Sebastian Bergmann <sebastian@php.net> wrote: >> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: >>> would you mind to explain this? >> >> "Foo|Bar", "array|string", etc. (still) make no sense to me. >> >> "scalar" makes sense to me although it is but an alias for >> "bool|float|int|string". >> > Would you feel differently if we combined union types with type aliasing? > > use Numeric = int | float; > > function foo(Numeric $bar) { ... }
looks also good for me (while directed to someone else) but i would still prefer function foo(int|float $bar) because it's more native and hence works finally the same way for every code which targets the minimum PHP version where it's available at the first look "use Numeric = int | float" looks gut, but you need namespaces to avoid collisions and the same thing could have a different meaning in different namespaces while "int|float" is very clear and could also be "myClassA|myClassB" without explicit declaration what could also be a problem with "use Numeric = int | float" is what happens with existing code if someone changes that line by add another type while functions don#t expect that one as input at the time they where written - that can't happen with "int|float" in the function declaration because it's a case-by-case decision anyways, it would be a good progress if PHP programmers would be able to declare type-hints for everything in hwatever way it is implemented phpdoc even warns when documentation block and type hints differ and it's something to enhance code quality compared to "i can't declare a typehint at all or need 3 different functions"
  101447
December 29, 2017 17:29 markus@fischer.name (Markus Fischer)
Hi all,

On 26.12.17 16:56, Sebastian Bergmann wrote:
> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: >> would you mind to explain this? > > "Foo|Bar", "array|string", etc. (still) make no sense to me. > > "scalar" makes sense to me although it is but an alias for > "bool|float|int|string".
I followed the discussion and found it interesting how strong the focus shifted about the discussion of the practical use cases. I would be for union types or scalars in ab instant, but I never had reason to scan our code-base and figure what would make really sense. Mind you this is a private codebase (Laravel based, as can be seen by some of the class names) but one where we tend to be very explicit about documenting everything, thus I knew I could just go ahead and extract the type hints using the '|' character and get back a pretty complete picture: $ grep -r '@param' *|grep \| | awk '{ print $4 }'|sort -u Attachment[]|Collection Attachment[]|null Builder|null Channel|Post|int|null Channel|int|null ClientInterface|null Client|int|null Collection|Attachment[] Collection|Channel[] Collection|Comment[] Collection|JsonapiModel[] Collection|Model[] Collection|Post[] DateTime|Carbon|string|null Dispatcher|null EloquentCollection|JsonapiModel[] Exception|null Group|Group[]|Client|Client[]|Channel|Channel[]|null Group|int|null JsonapiModel|null Model|int|null Post[]|null Post|int|null Profile|int|null ResponseInterface|null Throwable|null User|int|null \ArrayAccess|array|JsonapiModel[]|null array|false array|null int[]|int int|int[] int|null mixed|null null|LoggerInterface null|Model null|Model[]|Collection null|string string[]|Expression[] string|int string|null This is extracted from a codebase with ~400 files and ~43k LOC (incl. comments). I'm not saying anything like this is relevant codebase, but it's a project whose code quality I know well and I know the reason for every piece there. Since the discussion focuses on scalars here and ignoring all the nullables (they're auto-documented that way via PhpStorm) as well as ignoring the pseudo array-type hints, this leaves us really with only: - array|false Only 1 occurrence, used for crafting a remote HTTP call which has an interface which accepts either an array or false 🤷‍♀️ - string|int Only 1 occurrence, used for error codes which may come in either flavor, send back via HTTP somewhere I was surprised how less of a use we would really have for a) `scalar` itself and b) scalar unions. OTOH, typed array hints seem to be very useful as are class based union types. Although if one looks closely, it's clear this isn't a "union" problem, but rather an emulation due to the absence of Generics, e.g. Attachment[]|Collection Is clearly a replacement for something like Collection I hope I didn't distract to much from the discussion but though I throw in some data from an actual application. I'm sure there are much better OSS projects out there which could be used for such analysis. thanks, - Markus
  101449
December 29, 2017 17:33 lists@rhsoft.net ("lists@rhsoft.net")
Am 29.12.2017 um 18:29 schrieb Markus Fischer:
> On 26.12.17 16:56, Sebastian Bergmann wrote: >> Am 26.12.2017 um 16:46 schrieb lists@rhsoft.net: >>> would you mind to explain this? >> >> "Foo|Bar", "array|string", etc. (still) make no sense to me. >> >> "scalar" makes sense to me although it is but an alias for >> "bool|float|int|string". > > I followed the discussion and found it interesting how strong the focus > shifted about the discussion of the practical use cases
because a lot of people demand that instead realize that with union-types all that discussions would have ended because it's totally on the application side written in PHP after that
  101421
December 26, 2017 15:59 andreas@heigl.org (Andreas Heigl)
Hey All. 

> Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <sebastian@php.net>: > >> Am 24.12.2017 um 15:34 schrieb Fleshgrinder: >> I prepared a PR to add the `scalar` pseudo-type to PHP after the >> discussions around adding a `mixed` pseudo-type. I strongly believe that >> it makes sense to provide the most common primitive union types with >> handy aliases even if we are going to add union types in the future to PHP. > > Thank you, Richard, for working on this. > > I spent a lot of time this year introducing scalar type declarations into > existing code bases. In quite a few cases I was not able to do so because > the existing code works with parameters that can be of two or more scalar > types. With PHP 7.2, I can only document this outside of the code using > @param annotations (until the code has been refactored to work with only > one parameter type). > > With a "scalar" type declaration I would not have to fall back to @param > annotations and could express the type in actual syntax.
Just a stupid question from someone that isn't following all the discussions here. So forgive me if the question was already asked and answered. What would be wrong with a "composed type hint"? Something like int|float|double $numeric. Or array|Traversable $iterator? It would allow people to add "mixed" typehints without having to introduce multiple typehints that combine different scalar typehints. And it could even allow typehinting different Objects in one function. Yes, it allows people to shoot themselfes into their own feet. And I'd only allow that for parameter types and never ever for return types. But it might be an idea. Cheers Andreas
  101423
December 26, 2017 16:20 lisachenko.it@gmail.com (Alexander Lisachenko)
In some distant future it could be implemented in more natural way with
classes for primitive types and automatic boxing/unboxing for primitive
built-in types:

Php\Type\Object
Php\Type\Scalar
   ⌊ Php\Type\String
   ⌊ Php\Type\Integer
   ⌊ Php\Type\Float
   ⌊ Php\Type\Boolean
Php\Type\Array

And it will be easy to typehint all scalars via common parent class:

public function acceptsScalar(Scalar $scalarValue).

But all scalar objects in this case should be implemented as immutable or
should be passed as copy (like arrays). So, I would vote no for adding
special scalar typehint without mapping it to the common class or
interface, like iterable => Traversable, callable => Closure, etc

Best regards, Alexander

2017-12-26 18:59 GMT+03:00 Andreas Heigl <andreas@heigl.org>:

> Hey All. > > > Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <sebastian@php.net>: > > > >> Am 24.12.2017 um 15:34 schrieb Fleshgrinder: > >> I prepared a PR to add the `scalar` pseudo-type to PHP after the > >> discussions around adding a `mixed` pseudo-type. I strongly believe that > >> it makes sense to provide the most common primitive union types with > >> handy aliases even if we are going to add union types in the future to > PHP. > > > > Thank you, Richard, for working on this. > > > > I spent a lot of time this year introducing scalar type declarations into > > existing code bases. In quite a few cases I was not able to do so because > > the existing code works with parameters that can be of two or more scalar > > types. With PHP 7.2, I can only document this outside of the code using > > @param annotations (until the code has been refactored to work with only > > one parameter type). > > > > With a "scalar" type declaration I would not have to fall back to @param > > annotations and could express the type in actual syntax. > > Just a stupid question from someone that isn't following all the > discussions here. So forgive me if the question was already asked and > answered. > > What would be wrong with a "composed type hint"? Something like > int|float|double $numeric. Or array|Traversable $iterator? > > It would allow people to add "mixed" typehints without having to introduce > multiple typehints that combine different scalar typehints. And it could > even allow typehinting different Objects in one function. > > Yes, it allows people to shoot themselfes into their own feet. > > And I'd only allow that for parameter types and never ever for return > types. > > But it might be an idea. > > Cheers > > Andreas > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  101427
December 26, 2017 22:39 php@fleshgrinder.com (Fleshgrinder)
On 12/26/2017 5:20 PM, Alexander Lisachenko wrote:
> In some distant future it could be implemented in more natural way with > classes for primitive types and automatic boxing/unboxing for primitive > built-in types: > > Php\Type\Object > Php\Type\Scalar > ⌊ Php\Type\String > ⌊ Php\Type\Integer > ⌊ Php\Type\Float > ⌊ Php\Type\Boolean > Php\Type\Array > > And it will be easy to typehint all scalars via common parent class: > > public function acceptsScalar(Scalar $scalarValue). > > But all scalar objects in this case should be implemented as immutable or > should be passed as copy (like arrays). So, I would vote no for adding > special scalar typehint without mapping it to the common class or > interface, like iterable => Traversable, callable => Closure, etc > > Best regards, Alexander >
This is what I would like to see but making the primitives objects without too much BC is a complicated thing to achieve. Auto-boxing could be a solution. However, we would need many new things and new things are in general not well received in the PHP world if they replace other things. -- Richard "Fleshgrinder" Fussenegger