[RFC] [DISCUSSION] Scalar Pseudo-type

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by Nikita Popov — view source

unread

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

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by Sebastian Bergmann — view source

unread

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.

6 years ago by Niklas Keller — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

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?

6 years ago by Sebastian Bergmann — view source

unread

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".

6 years ago by lists@rhsoft.net — view source

unread

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

6 years ago by Larry Garfield — view source

unread

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

Foo & Bar makes total sense
int|float makes total sense
int & string is illogical so wouldn't matter anyway
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

6 years ago by lists@rhsoft.net — view source

unread

Am 26.12.2017 um 19:18 schrieb Larry Garfield:

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

Foo & Bar makes total sense

int|float makes total sense

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

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

6 years ago by Rowan Collins — view source

unread

Am 26.12.2017 um 19:18 schrieb Larry Garfield:

If I may, I think the argument has always been that

Foo & Bar makes total sense

int|float makes total sense

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]

6 years ago by Larry Garfield — view source

unread

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

Foo & Bar makes total sense

int|float makes total sense

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

6 years ago by lists@rhsoft.net — view source

unread

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"

6 years ago by Tony Marston — view source

unread

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

6 years ago by Fleshgrinder — view source

unread

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

Foo & Bar makes total sense

int|float makes total sense

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

6 years ago by Rowan Collins — view source

unread

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]

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by Stephen Reay — view source

unread

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

--

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.

6 years ago by Larry Garfield — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

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/

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

Am 29.12.2017 um 18:18 schrieb Fleshgrinder:

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

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

Am 29.12.2017 um 18:24 schrieb Fleshgrinder:

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

6 years ago by Sebastian Bergmann — view source

unread

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.

6 years ago by lists@rhsoft.net — view source

unread

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?

6 years ago by Stephen Reay — view source

unread

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.

6 years ago by Nikita Popov — view source

unread

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

Foo & Bar makes total sense

int|float makes total sense

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

6 years ago by lists@rhsoft.net — view source

unread

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

6 years ago by Fleshgrinder — view source

unread

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?

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

6 years ago by lists@rhsoft.net — view source

unread

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

6 years ago by Christoph M. Becker — view source

unread

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

6 years ago by Sebastian Bergmann — view source

unread

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().

6 years ago by Sara Golemon — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

Am 26.12.2017 um 20:15 schrieb Sara Golemon:

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"

6 years ago by Markus Fischer — view source

unread

Hi all,

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

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

6 years ago by lists@rhsoft.net — view source

unread

Am 29.12.2017 um 18:29 schrieb Markus Fischer:

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

6 years ago by Andreas Heigl — view source

unread

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

6 years ago by Alexander Lisachenko — view source

unread

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

6 years ago by Fleshgrinder — view source

unread

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

6 years ago by Tony Marston — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

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!"

6 years ago by Tony Marston — view source

unread

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

6 years ago by Lester Caine — view source

unread

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

6 years ago by lists@rhsoft.net — view source

unread

Am 30.12.2017 um 11:37 schrieb Lester Caine:

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

6 years ago by Tony Marston — view source

unread

wrote in message news:28ba9e6a-a3f2-2547-d294-f3a1710d5337@rhsoft.net...

Am 30.12.2017 um 11:37 schrieb Lester Caine:

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

6 years ago by Michael Morris — view source

unread

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).

6 years ago by lists@rhsoft.net — view source

unread

Am 30.12.2017 um 22:55 schrieb Michael Morris:

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

6 years ago by Tony Marston — view source

unread

"Michael Morris" wrote in message
news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com...

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.

<snip>

--
Tony Marston

6 years ago by lists@rhsoft.net — view source

unread

Am 31.12.2017 um 11:27 schrieb Tony Marston:

"Michael Morris" wrote in message
news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com...

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?

6 years ago by Dustin Wheeler — view source

unread

Am 31.12.2017 um 11:27 schrieb Tony Marston:
"Michael Morris" wrote in message news:CAEUnE0e67q2HMX8bmFjy5Mx8GMfxD=dNbSwF9cSuYntyn8xP8A@mail.gmail.com...

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.

6 years ago by Tony Marston — view source

unread

"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

6 years ago by lists@rhsoft.net — view source

unread

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

6 years ago by Tony Marston — view source

unread

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

6 years ago by Marco Pivetta — view source

unread

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/

6 years ago by Tony Marston — view source

unread

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

6 years ago by Tony Marston — view source

unread

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

6 years ago by Lester Caine — view source

unread

Please do not quote large swaths of Tony Marston's crap. He's an
unrepentant liar, braggart and trouble maker that most of the list has
on ignore since the admins can't be bothered to do their job and kick him.

I'll ignore the slander ... but perhaps now it the time that I simply
cut my poor clients loose and leave it up to them to keep their websites
working. Certainly the amount of time wasted coping with CRAP windows
updates such as happened last week, the minefield these days of keeping
Linux servers actually working and the problems of prioritising just
where to spend the remaining time to just keep currently live sites
working leaves no time to do any NEW work! OH and the bastards in the US
who steal .com domains for porn crap and ICANN does nothing to protect
us from !!! At least non US controlled domains are honest when we PAY to
renew! Another job to waste time on this week :( So NO I DON'T NEED
STRICT TYING ... THE DATABASE INTERFACE TAKES CARE OF LIMITS AND VALUES
THAT int DOES TOTALLY NOTHING FOR !!!!

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

6 years ago by Tony Marston — view source

unread

"Lester Caine" wrote in message
news:a1bb2452-3969-ca72-cf19-4ca4bcd9074d@lsces.co.uk...

Please do not quote large swaths of Tony Marston's crap. He's an
unrepentant liar, braggart and trouble maker that most of the list has
on ignore since the admins can't be bothered to do their job and kick
him.

Just because you don't like what I write does not give you reason to call it
crap.

You call me an unrepentant liar - can you point to anything that I have said
that has proven to be a lie?

You call me a braggart - but at least I have a code base that is still going
strong after 15 years without using any of those optional extras that have
been added to the language starting with PHP 5.

You call me a trouble maker - what trouble have I made and for whom?

You should learn to keep your insults to yourself.

--
Tony Marston

6 years ago by Chris Riley — view source

unread

Hi,

How useful is "scalar" as a type hint? I'm not sure it provides any benefit
over "mixed".

Would it not be better to copy Hack and instead introduce two type hints:
"num" (or "number") which is int|float and "arraykey" which is string|int?

To me, these are much more useful pseudo types than "scalar" which gives me
no usable guarantees over the type of data a function/method is receiving.

~C

"Lester Caine" wrote in message
news:a1bb2452-3969-ca72-cf19-4ca4bcd9074d@lsces.co.uk...

Please do not quote large swaths of Tony Marston's crap. He's an
unrepentant liar, braggart and trouble maker that most of the list has
on ignore since the admins can't be bothered to do their job and kick
him.

Just because you don't like what I write does not give you reason to call
it
crap.

You call me an unrepentant liar - can you point to anything that I have
said
that has proven to be a lie?

You call me a braggart - but at least I have a code base that is still
going
strong after 15 years without using any of those optional extras that have
been added to the language starting with PHP 5.

You call me a trouble maker - what trouble have I made and for whom?

You should learn to keep your insults to yourself.

--
Tony Marston

6 years ago by Sebastian Bergmann — view source

unread

Am 02.01.2018 um 14:37 schrieb Chris Riley:

How useful is "scalar" as a type hint? I'm not sure it provides any benefit
over "mixed".

scalar has the benefit of exluding arrays, objects, and resources.

6 years ago by Michael Morris — view source

unread

This was supposed to go to the list as well.

Please do not quote large swaths of Tony Marston's crap. He's an
unrepentant liar, braggart and trouble maker that most of the list has
on ignore since the admins can't be bothered to do their job and kick
him.

I'll ignore the slander ...

Before the admins come yelling at me over list rules I want to point out
that was sent to you personally, not to the list as a whole.

As for the rest of your reply, for both backwards compatibility and ease
of learning reasons it is impossible to change PHP into a strongly typed
language. No one has proposed that, at least not me. What I and several
others have proposed is making strong typing available to those who want it
in a manner that is backwards compatible. Argue against that if you must.

[RFC] [DISCUSSION] Scalar Pseudo-type

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL