Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

Posted by Fleshgrinder 
Fleshgrinder
[PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 24, 2017 03:40PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 24, 2017 05:40PM
On Sun, Dec 24, 2017 at 3:34 PM, Fleshgrinder <[email protected]> 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
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 24, 2017 05:50PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 24, 2017 06:30PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 02:50PM
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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Niklas Keller
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 04:40PM
>
> 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

>
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?

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sebastian Bergmann
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 05:00PM
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".

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Andreas Heigl
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 05:10PM
Hey All.

> Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <[email protected]>:
>
>> 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
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Alexander Lisachenko
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 05:30PM
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 <[email protected]>:

> Hey All.
>
> > Am 26.12.2017 um 14:38 schrieb Sebastian Bergmann <[email protected]>:
> >
> >> 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
>
>
Larry Garfield
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 07:20PM
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
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sara Golemon
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 08:20PM
On Tue, Dec 26, 2017 at 10:56 AM, Sebastian Bergmann <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 26, 2017 11:50PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Am 26.12.2017 um 20:15 schrieb Sara Golemon:
> On Tue, Dec 26, 2017 at 10:56 AM, Sebastian Bergmann <[email protected]> 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"

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 27, 2017 11:00AM
On 26 December 2017 18:35:29 GMT+00:00, "[email protected]" <[email protected]> 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 12:30AM
On Wednesday, December 27, 2017 3:50:54 AM CST Rowan Collins wrote:
> On 26 December 2017 18:35:29 GMT+00:00, "[email protected]"
<[email protected]> 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
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"

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Tony Marston
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 09:10AM
wrote in message news:[email protected]
>
>
>
>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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 01:10PM
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, "[email protected]"
> <[email protected]> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rowan Collins
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 01:30PM
On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder <[email protected]> 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]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 02:00PM
On 12/29/2017 1:26 PM, Rowan Collins wrote:
> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder
> <[email protected]> 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
Am 29.12.2017 um 09:04 schrieb Tony Marston:
> wrote in message news:[email protected]
>>
>> 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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stephen Reay
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 03:30PM
> On 29 Dec 2017, at 19:56, Fleshgrinder <[email protected]> wrote:
>
>> On 12/29/2017 1:26 PM, Rowan Collins wrote:
>> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder
>> <[email protected]> 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.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 04:10PM
On Friday, December 29, 2017 8:20:14 AM CST Stephen Reay wrote:
> > On 29 Dec 2017, at 19:56, Fleshgrinder <[email protected]> wrote:
> >> On 12/29/2017 1:26 PM, Rowan Collins wrote:
> >> On 29 December 2017 12:08:16 GMT+00:00, Fleshgrinder
> >>
> >> <[email protected]> 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
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/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Nikita Popov
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 04:40PM
On Fri, Dec 29, 2017 at 1:08 PM, Fleshgrinder <[email protected]> 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, "[email protected]"
> > <[email protected]> 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
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



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fleshgrinder
Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type
December 29, 2017 06:20PM
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

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login