Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
https://wiki.php.net/rfc/scalar_type_hinting_with_cast#vote
Andrea Faulds
http://ajf.me/
Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
I have postponed the vote after further thought. It’s been a while since this was discussed on the list.
However, it is my intent to open voting properly at some point soon, if all goes to plan.
--
Andrea Faulds
http://ajf.me/
I have postponed the vote after further thought. It’s been a while since this was discussed on the list.
However, it is my intent to open voting properly at some point soon, if all goes to plan.
I have withdrawn the RFC. I do not feel anymore that it is the way forward with scalar type hints in PHP.
Andrea Faulds
http://ajf.me/
hi Andrea,
I have postponed the vote after further thought. It’s been a while since this was discussed on the list.
However, it is my intent to open voting properly at some point soon, if all goes to plan.
I have withdrawn the RFC. I do not feel anymore that it is the way forward with scalar type hints in PHP.
Sigh. Here we go again.
I do not think we will ever reach an agreement on the list before the
RFC goes to the voting phase. That's why I think the RFC should
contain the most requested options and go with them. Any further
discussions will simply create more confusions and yet again move to a
dead end, we all lose.
It would be great if there are two sets of options:
- One about having scalar typed arguements, hinted or not, simple
yes/no, so we at least agree on having the feature - a set of options about how should it work
. strict
. what the rfc describes in its last state
. matching, if possible at all, current casting, following what
(int)$foo and co or whatever is considered as "the common casting php
way"
I am not saying these are the only options or only the correct ones,
there may be other. I only would like to get this sorted out sooner
rather than later.
If we agree on the feature itself and we do not see a clear majority
on one point or another, let take the top two options and try to
figure what has to be changed to get a majority (2nd phase vote).
To be more clear: We must get a decision here. I am convinced that
this is a top requested feature, since very long. Delay it forever
only because we are unable to find a concensus sounds pretty bad. Let
get us together to finally have this feature implemented, in the best
possible way.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hello,
thinking a bit again on the whole topic, which I thought I was pretty much
completely opposed to because of the arbitrary-new-set-of-rules issue in
die validation details, I noticed that from my writing PHP code, there is
a single thing that I really would like to be able to express as a type
hint. It would be a different kind of compromise. I wonder whether that
would please enough of the mysterious group of people who want such a
feature somehow.
Idea: have a "scalar" type hint. Have it admit null, int, float etc, but
not array, not object, and maybe not resource. No type juggling, casting,
or anything else that messes with the passed in zval - just a check that it
is scalar.
I come to this idea because in practise, what I often find myself checking
inside functions, is "if (is_array($arg) || is_object($arg)) fail; -
because these kinds of arguments tend to immediately mess up when treated
like scalars in further expressions in the function - while the usual type
juggling for scalar types works out fine in most other cases.
What do you think?
best regards
Patrick
Hi!
- One about having scalar typed arguements, hinted or not, simple
yes/no, so we at least agree on having the feature
I'm not sure how that would work. We agree on having what feature?
Having coercive typing and having strict typing are two different
options, working in different way and implying different coding
approaches. And then there's also a third option which is a "compromise"
approach where it is sometimes strict and sometimes not depending on a
matrix of choices, and different matrices would work in different way.
If I agree, for example, that coercive model is helpful - that doesn't
mean I want complete strict typing, and I certainly would prefer none
for now - in hope I would succeed convincing the majority in the future
in the merits of coercive typing approach - than having strict model
implemented now and closing the door for the coercive one forever. So I
don't see how "at least agree" without specifying what we agreeing on
works out.
To be more clear: We must get a decision here. I am convinced that
this is a top requested feature, since very long. Delay it forever
Is there any data to support this conviction that this is not merely
requested now and then, but it is a top requested feature since very
long? Note that none of the languages most close to PHP have it.
Also, I did a poll one on stackoverflow:
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php
and it's not on top at all, though it is among the requested ones.
However, having no consensus on it, saying "let's get together and make
something" does not look like a good idea to me, because there are
opportunity costs to prematurely having "something" that is not
satisfactory.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
- One about having scalar typed arguements, hinted or not, simple
yes/no, so we at least agree on having the featureI'm not sure how that would work. We agree on having what feature?
Having coercive typing and having strict typing are two different
options, working in different way and implying different coding
approaches. And then there's also a third option which is a "compromise"
approach where it is sometimes strict and sometimes not depending on a
matrix of choices, and different matrices would work in different way.
If I agree, for example, that coercive model is helpful - that doesn't
mean I want complete strict typing, and I certainly would prefer none
for now - in hope I would succeed convincing the majority in the future
in the merits of coercive typing approach - than having strict model
implemented now and closing the door for the coercive one forever. So I
don't see how "at least agree" without specifying what we agreeing on
works out.To be more clear: We must get a decision here. I am convinced that
this is a top requested feature, since very long. Delay it foreverIs there any data to support this conviction that this is not merely
requested now and then, but it is a top requested feature since very
long? Note that none of the languages most close to PHP have it.
Most?
Python has it, java too, ruby and perl not. We can continue to list those
having them or not, not sure that brings much to this discussion.
Also, I did a poll one on stackoverflow:
http://programmers.stackexchange.com/questions/27564/what-features-would-you-like-to-have-in-php
and it's not on top at all, though it is among the requested ones.
However, having no consensus on it, saying "let's get together and make
something" does not look like a good idea to me, because there are
opportunity costs to prematurely having "something" that is not
satisfactory.
Everyone I asked wants it, be at conferences, UGs, or devolopers of one of
the top tools or framework out there. There was also
http://www.php-vote.com/browse/latest showing in the top requests.
In any case, this endless discussion leads nowhere and we are not going to
have anything done using such debates and arguing.
Cheers,
--
Pierre
Hi!
Most?
Python has it, java too, ruby and perl not. We can continue to list
those having them or not, not sure that brings much to this discussion.
Only Python 3 has it, and I'm not sure bringing up Python 3, given its
known adoption issues, is the best example how we could plan PHP 7. In
any case, python 3 seems to be rather an exception than the rule amongst
scripting/dynamic languages, as it seems to me.
That brings to this discussion an argument that if people that have no
PHP baggage, no BC issues related to existing PHP code, etc. but working
in roughly the same space as PHP under roughly the same paradigms chose
to forego strict typing in that context - maybe it's not such a stupid
idea. Maybe we can learn from their experience too. We've often borrowed
from other languages, so consider it a case of negative borrowing :)
Everyone I asked wants it, be at conferences, UGs, or devolopers of one
of the top tools or framework out there. There was
also http://www.php-vote.com/browse/latest showing in the top requests.
This site has whopping 44 votes for "type hints with scalar types" and
52 for "100% unicode". It is rather hard for me to take it as a data
point that it is requested for everybody.
In any case, this endless discussion leads nowhere and we are not going
to have anything done using such debates and arguing.
OK, how do you propose to make anything done? Just ram through whatever
gets through the vote at random moment of time, whatever the
disagreements and issues are? Use some process which would allow us to
find a better solution? Which process?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
You give an option for float to int casting to truncate.
You give an example of truncating a positive float in that it rounds down
towards 0 - ie 1.5 becomes 1.
What happens with negaitve numbers ? Do you round towards zero or round in a
negative direction ? So, should -1.5 become -1 or -2 ? Or should it depend on
the floating point unit on the machine (not all do the same) ?
Currently PHP (CentOS on an AMD CPU) a cast to int converts -1.5 to -1.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
You give an option for float to int casting to truncate.
Where?
oa-res-27-90:php-src ajf$ sapi/cli/php -r 'function foobar(int $a) { var_dump($a); } foobar(1.5);'
Catchable fatal error: Argument 1 passed to foobar() must be of the type int, float given, called in Command line code on line 1 and defined in Command line code on line 1
If you mean under possible changes, it’s not a change that’s been made. It’d only be worth discussing within the context of making it truncate or round.
--
Andrea Faulds
http://ajf.me/
Hi!
oa-res-27-90:php-src ajf$ sapi/cli/php -r 'function foobar(int $a) {
var_dump($a); } foobar(1.5);'Catchable fatal error: Argument 1 passed to foobar() must be of the
type int, float given, called in Command line code on line 1 and
defined in Command line code on line 1
Calling this "scalar type hinting with cast" when it doesn't actually
cast in wide variety of cases sounds a bit misleading to me. It should
be called "scalar type checking with restricted casting" or something
like that.
I would also ask to clean up an RFC a bit and to clarify which of the
proposed choices and "possible changes" are actually being voted for
when somebody votes "yes".
In any case, I call everybody to vote against this RFC in this form,
since it introduces inconsistency between internal and user functions
and makes PHP have two different arbitrary sets of rules for implicit
conversions, and this can not be good for PHP.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Calling this "scalar type hinting with cast" when it doesn't actually
cast in wide variety of cases sounds a bit misleading to me. It should
be called "scalar type checking with restricted casting" or something
like that.
I'd agree it's not the best name. This is mainly a decision to make when this is documented or added to the language spec. If we change this thing's name, we should perhaps stop calling typed parameters 'type hints'.
I would also ask to clean up an RFC a bit and to clarify which of the
proposed choices and "possible changes" are actually being voted for
when somebody votes "yes".
The vote would be for the RFC as it is. Possible changes are things in the RFC I was uncertain on. I might hold votes on some of them, actually.
In any case, I call everybody to vote against this RFC in this form,
since it introduces inconsistency between internal and user functions
and makes PHP have two different arbitrary sets of rules for implicit
conversions, and this can not be good for PHP.
I had abandoned the RFC for this reason. However I gave up trying to improve zpp and make it consistent with user land hints, or adding user land hints which match zpp.
The problem is that we can't be consistent. Internal functions already live in this completely different world from user land functions. Nullability is handled differently. They use implicit casts in places as if they were user land functions with no parameter types at all. In other places they have strongly typed parameters. If they are passed invalid data, they usually just return NULL and emit a warning, though this depends on the function. User land functions, by contrast, will emit a recoverable error if the wrong type is passed. To make these two consistent would require massive backwards-compatibility breaks.
If we're just talking about casting, then this proposal does not alter casting behaviour, in fact I've been very careful not to touch it. It does, however, only accept a subset of the values zpp usually does. This is because it is a compromise between strict and weak parameter typing. While I understand you might like it to be fully weak like zpp, many userland developers are in favour of something stricter, thus the compromise. Unlike zpp's rules, at least these rules are clearly specified and prevent data loss.
Thanks!
Andrea Faulds
http://ajf.me/
-----Original Message-----
From: Andrea Faulds [mailto:ajf@ajf.me]
Sent: Sunday, September 14, 2014 3:08 PM
To: Stas Malyshev
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with CastThe problem is that we can't be consistent. Internal functions already
live in
this completely different world from user land functions. Nullability is
handled
differently. They use implicit casts in places as if they were user land
functions
with no parameter types at all. In other places they have strongly typed
parameters. If they are passed invalid data, they usually just return
NULLand
emit a warning, though this depends on the function. User land
functions, by
contrast, will emit a recoverable error if the wrong type is passed. To
make
these two consistent would require massive backwards-compatibility
breaks.
I honestly don't see why we can't be consistent for the simple types, or
at least strive to be as consistent as possible as opposed to introducing
a complete parallel universe for userland functions, that's inconsistent
with the entirety of the rest of PHP. We don't have to be consistent with
ALL internal functions, which obviously have the option of doing custom
checks and return failures not only if you fail to, say, pass on a string
- but also if that string is not of a special format. But then, you have
the option of doing that also in userland functions using custom code.
The question is not the customized cases - it's the standard behavioral
cases - comparing zpp rules for scalars and the newly-introduced rules for
userland scalars.
We could definitely strive to be consistent; Introduce some changes to
the implicit casting rules for internal functions and implement the very
same rules for this brand new userland functions. I'm definitely against
this RFC in its current form.
Zeev
I honestly don't see why we can't be consistent for the simple types, or
at least strive to be as consistent as possible as opposed to introducing
a complete parallel universe for userland functions, that's inconsistent
with the entirety of the rest of PHP. We don't have to be consistent with
ALL internal functions, which obviously have the option of doing custom
checks and return failures not only if you fail to, say, pass on a string
- but also if that string is not of a special format. But then, you have
the option of doing that also in userland functions using custom code.
The question is not the customized cases - it's the standard behavioral
cases - comparing zpp rules for scalars and the newly-introduced rules for
userland scalars.
OK, we could go for exactly what zpp does already. However, then we don’t have a compromise. We are siding with what you want, but most userland developers would prefer a strict system. While this would please you and perhaps some other folk on internals, and sure, it’d be consistent, it would not be popular with the wider PHP community. Similarly, we could go for a fully strict approach, which might please some userland developers, but wouldn’t please you.
I don’t want to go down this route. I’d prefer we compromise and keep PHP’s weakly-typed nature (an int can be accepted as a float or a string), but make it stricter (no data loss), thus arriving at a middle way.
We could definitely strive to be consistent; Introduce some changes to
the implicit casting rules for internal functions and implement the very
same rules for this brand new userland functions. I'm definitely against
this RFC in its current form.
I wanted to do that, but it has its problems. I do not have the time to go through and update literally thousands of tests that would be broken by zpp changes. Also, any change to zpp’s behaviour has backwards compatibility implications. There are some minor things I would like to change in zpp, which I will make an RFC for regardless of the success of this RFC (integer overflow should fail or at least raise a notice). Also, as I mentioned above, the resulting proposal would probably not please people who want strict types.
--
Andrea Faulds
http://ajf.me/
I honestly don't see why we can't be consistent for the simple
types, or at least strive to be as consistent as possible as opposed
to introducing a complete parallel universe for userland functions,
that's inconsistent with the entirety of the rest of PHP. We don't
have to be consistent with ALL internal functions, which obviously
have the option of doing custom checks and return failures not only
if you fail to, say, pass on a string - but also if that string is
not of a special format. But then, you have the option of doing
that also in userland functions using custom code. The question is
not the customized cases - it's the standard behavioral cases -
comparing zpp rules for scalars and the newly-introduced rules for
userland scalars.OK, we could go for exactly what zpp does already. However, then we
don’t have a compromise. We are siding with what you want, but most
userland developers would prefer a strict system. While this would
please you and perhaps some other folk on internals, and sure, it’d be
consistent, it would not be popular with the wider PHP community.
Similarly, we could go for a fully strict approach, which might please
some userland developers, but wouldn’t please you.I don’t want to go down this route. I’d prefer we compromise and keep
PHP’s weakly-typed nature (an int can be accepted as a float or a
string), but make it stricter (no data loss), thus arriving at a
middle way.
But this "compromise" introduces yet another set of casting rules. And
that is why will advocate and vote against this.
We can either have casting where:
function bar(int $foo) { }
bar("42");
Means the same as:
function bar($foo) { }
bar((int) "42");
Or we can have it as a strict cast, or we can have it like it currently
(ie, not at all). I can live with those three options, but not an
option where casting/checking does something different again.
cheers,
Derick
But this "compromise" introduces yet another set of casting rules. And
that is why will advocate and vote against this.We can either have casting where:
function bar(int $foo) { }
bar("42");Means the same as:
function bar($foo) { }
bar((int) "42”);
Is anyone really advocating for that? I thought people wanted zpp-style casting.
Andrea Faulds
http://ajf.me/
Or we can have it as a strict cast, or we can have it like it currently
(ie, not at all). I can live with those three options, but not an
option where casting/checking does something different again.
Is there an existing, documented, definition of "strict cast" which you
would approve of?
--
Rowan Collins
[IMSoP]
We can either have casting where:
function bar(int $foo) { } bar("42");Means the same as:
function bar($foo) { } bar((int) "42");Or we can have it as a strict cast, or we can have it like it currently
(ie, not at all). I can live with those three options, but not an
option where casting/checking does something different again.
I totally agree with this. I can understand any of the following:
- function f(int $a) { } == f( (int) $a); -- with NO notices
- function f(int $a) {} means $a must be exactly type int -- or
recoverable error is thrown - current behavior (no scalar type hints)
But a new set of rules that require a 23x7 table to describe what's
going on ... not a big fan.
--
Matthew Leverton
Hi,
As a userland guy, I'm against this one.
It seems a bit political ... A lot of people want either strict type
hints or type casting hints, but because the people on this list can't
get to agree on any of the two, this RFC tries to make a compromise
that, IMO, satisfies nobody. It's done not for the benefit of
everybody, but just so we can say that PHP has "scalar type hints".
I've said this in the RFC discussion thread: In order to satisfy both
sides, instead of arguing which is the one and true way, just
implement both.
That is also why I suggested altering the proposed syntax here from:
function foo(int $bar)
to:
function foo((int) $bar)
Whether it applies more strict rules or not, this RFC is clearly about
type casting hints, while the used syntax has so far only been used
for strict type hints. I know some would argue that this is a side
effect because you can't cast to a specific class type, but that's not
the point - the result is a strict type hint and that's what people
are used to. This is both inconsistent AND prevents PHP from having
strict scalar type hints in the future (because of the used syntax).
I (and I'm sure many others) would love both features separately, not
a hacky mix between the two.
Cheers,
Andrey.
It seems a bit political ... A lot of people want either strict type
hints or type casting hints, but because the people on this list can't
get to agree on any of the two, this RFC tries to make a compromise
that, IMO, satisfies nobody. It's done not for the benefit of
everybody, but just so we can say that PHP has "scalar type hints".
I've said this in the RFC discussion thread: In order to satisfy both
sides, instead of arguing which is the one and true way, just
implement both.
I’m not sure it satisfies nobody. I realise a lot of people would prefer strict types, but plenty are still in favour of this as a compromise:
http://strawpoll.me/2463199/r - Might not be representative, but I held a poll on Twitter and StackOverflow. There are the results. 67 would vote in favour of strict hints (à la Hack), and 36 would vote in favour of this RFC, with only 5 willing to vote against it, versus 10 voting against strict hints. Note that the options aren’t mutually exclusive.
That is also why I suggested altering the proposed syntax here from:
function foo(int $bar)
to:
function foo((int) $bar)
But it’s not a cast. Such a syntax would be misleading. You would reasonably expect the following two functions to be equivalent:
function foo($bar) { $bar = (int)$bar; }
function foo((int) $bar) { }
Yet they are not equivalent at all.
Whether it applies more strict rules or not, this RFC is clearly about
type casting hints, while the used syntax has so far only been used
for strict type hints.
Well, we haven’t had any scalar hints so far. It’s also worth noting that the documentation for PHP uses this style even though internal functions are not strict. Furthermore, scalar types in PHP are fundamentally different from non-scalar types. We do not have weak typing for non-scalars: there are no implicit casts between non-scalar types. However, we implicitly convert and juggle the scalar types all the time.
I know some would argue that this is a side
effect because you can't cast to a specific class type, but that's not
the point - the result is a strict type hint and that's what people
are used to. This is both inconsistent AND prevents PHP from having
strict scalar type hints in the future (because of the used syntax).
Strict hints would still be possible with different syntax. However, I’m not sure they’re a good idea. Strict hints would be abandoning PHP’s weakly-typed nature, and would segregate userland functions into two kinds: strict and non-strict. I also don’t expect that would pass internals anyway.
I don’t think permitting multiple options is really the way forward, that sounds like the worst of both worlds.
--
Andrea Faulds
http://ajf.me/
Hi,
It seems a bit political ... A lot of people want either strict type
hints or type casting hints, but because the people on this list can't
get to agree on any of the two, this RFC tries to make a compromise
that, IMO, satisfies nobody. It's done not for the benefit of
everybody, but just so we can say that PHP has "scalar type hints".
I've said this in the RFC discussion thread: In order to satisfy both
sides, instead of arguing which is the one and true way, just
implement both.I’m not sure it satisfies nobody. I realise a lot of people would prefer strict types, but plenty are still in favour of this as a compromise:
http://strawpoll.me/2463199/r - Might not be representative, but I held a poll on Twitter and StackOverflow. There are the results. 67 would vote in favour of strict hints (à la Hack), and 36 would vote in favour of this RFC, with only 5 willing to vote against it, versus 10 voting against strict hints. Note that the options aren’t mutually exclusive.
So, basically ... the poll shows nothing. :)
I was actually looking for that link (I took part in the poll), but
couldn't find it.
That is also why I suggested altering the proposed syntax here from:
function foo(int $bar)
to:
function foo((int) $bar)
But it’s not a cast. Such a syntax would be misleading. You would reasonably expect the following two functions to be equivalent:
function foo($bar) { $bar = (int)$bar; } function foo((int) $bar) { }Yet they are not equivalent at all.
They are not equivalent, because of the different rules that you're
proposing here, but it is a cast. And the fact that with this RFC
both would mean some kind of cast is happening, is simply bad.
Whether it applies more strict rules or not, this RFC is clearly about
type casting hints, while the used syntax has so far only been used
for strict type hints.Well, we haven’t had any scalar hints so far. It’s also worth noting that the documentation for PHP uses this style even though internal functions are not strict. Furthermore, scalar types in PHP are fundamentally different from non-scalar types. We do not have weak typing for non-scalars: there are no implicit casts between non-scalar types. However, we implicitly convert and juggle the scalar types all the time.
... and I responded to this in the next paragraph. Userland doesn't
case about internal differences, that's why they're called internal
and why people outside of php-internals have for so long been puzzled
why we only have array and object type hints.
I know some would argue that this is a side
effect because you can't cast to a specific class type, but that's not
the point - the result is a strict type hint and that's what people
are used to. This is both inconsistent AND prevents PHP from having
strict scalar type hints in the future (because of the used syntax).Strict hints would still be possible with different syntax. However, I’m not sure they’re a good idea. Strict hints would be abandoning PHP’s weakly-typed nature, and would segregate userland functions into two kinds: strict and non-strict. I also don’t expect that would pass internals anyway.
That's exactly what I'm talking about ... we already have a syntax for
strict typing, (and I want to put an emphais on this) regardless of
the reasons why, we do have strict type hints. I don't understand why
everybody is pretending that PHP doesn't have that feature just
because we're talking about scalars here.
Speaking strictly from a userland perspective, using that same syntax
for something different will be inconsistent and will cause confusion.
That another syntax could be used for strict typing in the future is
just not a serious thing to say.
As for the language's nature/philosophy/direction/whatever, I had
something written about that, but chose to discard it in order to
avoid that "discussion". Everybody is tired of talking about that.
I don’t think permitting multiple options is really the way forward, that sounds like the worst of both worlds.
You can't say it's the worst of both worlds when you have both worlds
in their entirety. And most importantly, they have always been two
separate worlds because they just don't make sense otherwise. I could
argue that this compromise RFC here is a mistake exactly because it is
trying to mix them.
Cheers,
Andrey.
... and I responded to this in the next paragraph. Userland doesn't
case about internal differences, that's why they're called internal
and why people outside of php-internals have for so long been puzzled
why we only have array and object type hints.
"Internal functions” refers to functions from extensions. It has no relation to internals, the mailing list.
That's exactly what I'm talking about ... we already have a syntax for
strict typing, (and I want to put an emphais on this) regardless of
the reasons why, we do have strict type hints. I don't understand why
everybody is pretending that PHP doesn't have that feature just
because we're talking about scalars here.
Nobody’s arguing we don’t already have strict type hints. I’m arguing strict hints don’t make sense for scalars. Note that we document strict (array, object) parameter types and non-strict (scalar) parameter types in the same way in our documentation.
Speaking strictly from a userland perspective, using that same syntax
for something different will be inconsistent and will cause confusion.
That another syntax could be used for strict typing in the future is
just not a serious thing to say.
Why is it "not a serious thing to say”? I don’t understand.
You can't say it's the worst of both worlds when you have both worlds
in their entirety.
No, you can. Allowing both options can be “the worst of both worlds”. This is just a trivial matter of semantics, though.
And most importantly, they have always been two
separate worlds because they just don't make sense otherwise.
Have they? We already mix strict and non-strict typing in PHP. Functions taking objects, internal or not, will error if you pass the wrong type of object. Internal functions taking scalars will not error and instead cast, at least most of the time.
Andrea Faulds
http://ajf.me/
... and I responded to this in the next paragraph. Userland doesn't
case about internal differences, that's why they're called internal
and why people outside of php-internals have for so long been puzzled
why we only have array and object type hints."Internal functions” refers to functions from extensions. It has no relation to internals, the mailing list.
I'm aware of that, hence why I said 'php-internals' to refer to the
mailing list. Again, userland devs don't care about that - PHP is
their language and they only care how we/they interact with it, not
what happens under the hood. Imagine for a moment that you've never
been involved in the development of PHP itself and you'll see how what
I say makes a lot of sense.
That's exactly what I'm talking about ... we already have a syntax for
strict typing, (and I want to put an emphais on this) regardless of
the reasons why, we do have strict type hints. I don't understand why
everybody is pretending that PHP doesn't have that feature just
because we're talking about scalars here.Nobody’s arguing we don’t already have strict type hints. I’m arguing strict hints don’t make sense for scalars. Note that we document strict (array, object) parameter types and non-strict (scalar) parameter types in the same way in our documentation.
And because you don't think it makes sense (and that might mean you
don't think it now), you're ignoring it. That's also a reason why
the documentation is done that way - nobody has thought of writing it
differently, because they didn't have to. The docs can always be
updated, but once the language changes, there's no going back.
Speaking strictly from a userland perspective, using that same syntax
for something different will be inconsistent and will cause confusion.
That another syntax could be used for strict typing in the future is
just not a serious thing to say.Why is it "not a serious thing to say”? I don’t understand.
Because it's obvious that you're not even thinking of that as a
possibility. What would that syntax be? "function foo([int] $bar)" ?
As I already said, we already have and use a syntax for strict typing.
This RFC uses that same syntax for something different and that's
wrong, hence why the RFC should be changed, not the other way around.
You can't say it's the worst of both worlds when you have both worlds
in their entirety.No, you can. Allowing both options can be “the worst of both worlds”. This is just a trivial matter of semantics, though.
I'll ... just say that it's also the best of both worlds and agree to
disagree, I think you got the idea.
And most importantly, they have always been two
separate worlds because they just don't make sense otherwise.Have they? We already mix strict and non-strict typing in PHP. Functions taking objects, internal or not, will error if you pass the wrong type of object. Internal functions taking scalars will not error and instead cast, at least most of the time.
I already noted multiple times that I'm talking as a userland
developer and that no userland developer (generally speaking, of
course) cares about internal functions.
Cheers,
Andrey.
I'm aware of that, hence why I said 'php-internals' to refer to the
mailing list. Again, userland devs don't care about that - PHP is
their language and they only care how we/they interact with it, not
what happens under the hood.
Yes. Internal functions are used by userland developers. Userland developers do care about internal functions. If we get rid of explode() or json_decode() tomorrow, userland developers will complain.
Perhaps I should explain what an “internal function” is in PHP parlance. An internal function is one which is exposed to userland, but is implemented in C via an extension, rather than in PHP. Examples include literally every function in PHP’s documentation.
Speaking strictly from a userland perspective, using that same syntax
for something different will be inconsistent and will cause confusion.
That another syntax could be used for strict typing in the future is
just not a serious thing to say.Why is it "not a serious thing to say”? I don’t understand.
Because it's obvious that you're not even thinking of that as a
possibility. What would that syntax be? "function foo([int] $bar)" ?
function foo(int! $bar)
Though it’s true, I don’t want to have them.
As I already said, we already have and use a syntax for strict typing.
This RFC uses that same syntax for something different and that's
wrong, hence why the RFC should be changed, not the other way around.
I know you have a problem with using similar syntax for non-strict typing, but I don’t.
--
Andrea Faulds
http://ajf.me/
I'm aware of that, hence why I said 'php-internals' to refer to the
mailing list. Again, userland devs don't care about that - PHP is
their language and they only care how we/they interact with it, not
what happens under the hood.Yes. Internal functions are used by userland developers. Userland developers do care about internal functions. If we get rid of
explode()orjson_decode()tomorrow, userland developers will complain.Perhaps I should explain what an “internal function” is in PHP parlance. An internal function is one which is exposed to userland, but is implemented in C via an extension, rather than in PHP. Examples include literally every function in PHP’s documentation.
So why are we talking about "internal functions" at all? And what does
that have to do with type hints?
We know that explode() accepts strings, integers, floats ... we know
that's called type juggling. Strict type hints or type cast hints
wouldn't affect that. All we want is to be able to do the following:
function foo(int $bar) {} // don't accept anything that's not an integer
function foo((int) $bar) {} // cast $bar to an integer (if
possible, of course)
(you can ignore the syntax for that example)
That is what we want to be able to write in in a PHP application,
deffinately NOT what should be done to what I call "native" PHP
functions or "internal" PHP functions to you. We just assume those
functions don't have any kind of type hints and nobody has a problem
with that.
Cheers,
Andrey.
Perhaps I should explain what an “internal function” is in PHP parlance. An internal function is one which is exposed to userland, but is implemented in C via an extension, rather than in PHP. Examples include literally every function in PHP’s documentation.
So why are we talking about "internal functions" at all? And what does
that have to do with type hints?
Some of those internal functions, implemented in C, but used by userland
developers every day, have type hinting built into them, and some don't.
For instance, try passing a non-numeric string to mktime().
As Andrea points out, one of the big problems in this discussion is that
those internal functions aren't actually consistent with one another -
some of the logic is built into zned_parse_parameters, but fallback
behaviour and additional checks are implemented ad hoc all over the
standard library.
As a userland developer, this is actually rather confusing, and I'd be
interested to know what it would take to come up with some finite set of
base behaviours that documented what each function would do given the
"wrong" types.
--
Rowan Collins
[IMSoP]
As Andrea points out, one of the big problems in this discussion is that
those internal functions aren't actually consistent with one another - some
of the logic is built into zned_parse_parameters, but fallback behaviour
and additional checks are implemented ad hoc all over the standard library.
This is exactly the issue we are battling here. One side wants to be
consistent with inconsistencies (and tbh quite confusing) while the other
side wants to allow userland implemented APIs to actually be consistent.
I am not judging any of these sides but we are heading to a status quo
here, for no good reason. We all know that this is a feature desired by a
very large of our users. Let not block it.
One side wants to be consistent with inconsistencies (and tbh quite
confusing) while the other side wants to allow userland implemented
APIs to actually be consistent.
I'm not sure that's quite fair. The only thing that would be consistent
with existing userland functionality is strict typing, fatal error on
incorrect type (since that's what class "hints" do; they're more like
assertions than anything else); I'm pretty sure nobody is arguing for that.
There's also definitely more than two "sides" here - there are lots of
people, with lots of different opinions. I'm guessing what you want is
for it to be consistent with existing userland casts? i.e. function
foo(int $bar) { /* ... / } is just syntactic sugar for function
foo($bar) { $bar = (int)$bar; / ... */ }
Perhaps it would be better to discuss how useful that would be as a
feature, rather than just how consistent it is or isn't with other parts
of the language.
--
Rowan Collins
[IMSoP]
Hi!
This is exactly the issue we are battling here. One side wants to be
consistent with inconsistencies (and tbh quite confusing) while the other
side wants to allow userland implemented APIs to actually be consistent.
It's not the issue here. Nobody wants 100% of functions to do the same,
and everybody knows there will be exceptions when some functions can not
accept all values covered by type, or can accept multiple types but only
in certain situations, etc. etc. What we want is to have one set of
rules (yes, again, not covering 100% of functions, both user and
internal, but covering most of them in the same way) instead of two
different sets of rules.
I am not judging any of these sides but we are heading to a status quo
here, for no good reason. We all know that this is a feature desired by a
very large of our users. Let not block it.
Nobody is "blocking it". What we're talking about is not making
inconsistent arbitrary implementation that prevents us from making a
consistent one (since if we introduce two inconsistent sets of rules, we
won't be able to make it one consistent set of rules until the next
major at least). In my opinion, it is better not to have it until it's
ready than have it in a broken way just because "users want it" so we
have no time to do it right.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Stas Malyshev wrote (on 15/09/2014):
It's not the issue here. Nobody wants 100% of functions to do the same,
and everybody knows there will be exceptions when some functions can not
accept all values covered by type, or can accept multiple types but only
in certain situations, etc. etc. What we want is to have one set of
rules (yes, again, not covering 100% of functions, both user and
internal, but covering most of them in the same way) instead of two
different sets of rules.
I agree that 100% is an unrealistic goal, but I don't think I've yet
seen someone actually point at a documented set of rules that even 80%
of current functions follow. I guess there is a default/normal usage of
ZPP etc that most internal functions use, but I have yet to find the
documentation on what this actually is (README.PARAMETER_PARSING_API
lists the C types you have to use, but not the PHP types & values that
can be provided by the user, or what happens if they don't).
Apologies if I'm missing something obvious here.
Regards,
Rowan Collins
[IMSoP]
Hi!
I agree that 100% is an unrealistic goal, but I don't think I've yet
seen someone actually point at a documented set of rules that even 80%
of current functions follow. I guess there is a default/normal usage of
The rules are in zpp, and every function that uses zpp automatically
follows them.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Stas Malyshev wrote (on 15/09/2014):
Hi!
I agree that 100% is an unrealistic goal, but I don't think I've yet
seen someone actually point at a documented set of rules that even 80%
of current functions follow. I guess there is a default/normal usage of
The rules are in zpp, and every function that uses zpp automatically
follows them.
For those of us that aren't fluent in C, it would be great if someone
could document those rules, or point at a readable piece of code which
is specifically relevant to this discussion.
As I understand it, it's also not quite true to say that everything
automatically follows them, since functions can a) react how they want
to a "failure" of ZPP, and b) perform any extra checks and conversions
they want in addition to ZPP. From an engine perspective, the rules of
ZPP itself may seem like a single unit, but from a userland PoV, the
function's overall behaviour that is a "black box".
Please correct me if I've misunderstood that.
Regards,
Rowan Collins
[IMSoP]
Hi!
The vote would be for the RFC as it is. Possible changes are things
in the RFC I was uncertain on. I might hold votes on some of them,
actually.
I'm sorry, but this makes little sense to me. There are a number of
mutually contradictory options here, how you can vote for them "as it
is"? Only one of them can be implemented in code. If everybody agrees
that one of them should be so, then just remove the others. If there's
disagreement then how people can vote "yes" having contradictory ideas
in mind? One of them would be voting "yes" for the opposite of what he
thought he's voting. If the specific choices do not matter, just choose
one of the options - if they're so insignificant nobody would care if
you end up with another. In any case, there should be a clear
understanding of what is actually proposed, instead of having 5
branching points for potentially 32 different RFCs. Or, if you
absolutely can't make up your mind you can offer the options for the
vote. But there should be some specificity.
Otherwise the vote is meaningless - it's not the vote for specific
implementation but just for some vague "let's do something I don't care
what it is" and I don't think such votes make sense. Please choose
something and put it to a vote. If it doesn't work, we can have
different try or maybe we can just see there's no consensus on this for
now, but at least we'd be clear and not think we have consensus on
something but not know what actually it is.
The problem is that we can't be consistent. Internal functions
already live in this completely different world from user land
functions. Nullability is handled differently. They use implicit
If we can't make it work well, maybe we should clean it up first instead
of making it worse.
If we're just talking about casting, then this proposal does not
alter casting behaviour, in fact I've been very careful not to touch
it. It does, however, only accept a subset of the values zpp usually
Casting while passing parameters is part of the casting behavior.
does. This is because it is a compromise between strict and weak
parameter typing. While I understand you might like it to be fully
Again, my opinion is that bad compromise is worse than not having any
implementation, because it closes future possibilities for better
solution. Of course, there's a risk better one would never come, so
everyone has to decide if they want "at least something" now or have a
better one latter.
weak like zpp, many userland developers are in favour of something
stricter, thus the compromise. Unlike zpp's rules, at least these
rules are clearly specified and prevent data loss.
I'm not sure why is this attention to data loss. In most scenarios when
we're not talking about banking applications etc. if you expect a number
and you've got a string "123abc", treating it as 123 is fine. No
useful data is lost, since "abc" part passed to a numeric function is
not useful data, it's garbage. Of course, for some app if you have
garbage in data you're supposed to stop the app and wait for the human
to arrive and clean up because it's too sensitive to trust a computer to
figure it out. But in more common case just ignoring the garbage would
work fine.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
The vote would be for the RFC as it is. Possible changes are things
in the RFC I was uncertain on. I might hold votes on some of them,
actually.I'm sorry, but this makes little sense to me. There are a number of
mutually contradictory options here, how you can vote for them "as it
is”?
The “possible changes” section only details possible changes, that is, changes to the RFC that could be made, but have not been. So you would be voting for the RFC without any of those changes. If those changes were made, they would cease to be possible changes.
--
Andrea Faulds
http://ajf.me/
Hi!
The “possible changes” section only details possible changes, that
is, changes to the RFC that could be made, but have not been. So you
OK, so by "possible changes" you mean things that could have been into
RFC, but were rejected and are not part of the RFC? Then I agree it is
clear but I'd feel better if it was explicitly stated there that these
things are not part of the RFC and the vote.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
Hi!
The “possible changes” section only details possible changes, that
is, changes to the RFC that could be made, but have not been. So youOK, so by "possible changes" you mean things that could have been into
RFC, but were rejected and are not part of the RFC? Then I agree it is
clear but I'd feel better if it was explicitly stated there that these
things are not part of the RFC and the vote.
The section now says "For points I'm unsure on, this section lists possible future changes to the RFC.”.
Andrea Faulds
http://ajf.me/
You give an option for float to int casting to truncate.
Where?
Possible Changes
Float to Int Casting Rules
...
This could be relaxed for semi-representable values. So 1.5 could be allowed
for an int parameter (casted to 1).
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h
You give an option for float to int casting to truncate.
Where?
Possible Changes Float to Int Casting Rules...
This could be relaxed for semi-representable values. So 1.5 could be allowed for an int parameter (casted to 1).
That's one thing I do not like much. If one accepts both int and
float, numeric should be used instead. But allowing float for int and
raises warnings on data losses is just awkward imho.
--
Pierre
@pierrejoye | http://www.libgd.org
hi Andrea,
Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Great job!
It brings also some clarity and sense to type casting, at least for this area.
I do not see much of a problem with the small delta with existing
casting. I am not sure about the recoverable error, especially when
old codes will use new implementations, it may have a bad impact
depending on how the errors are a managed in a given library. But
there is no BC per se in existing codes due to this.
All in all, I will vote +1. No matter what we think what PHP should
do, remain or be, this addition has been a long due request from the
waste majority of our users. Let see what they think about it.
Hopefully some lead devs of the major tools/libs/frameworks will post
their views here.
Cheers.
Pierre
@pierrejoye | http://www.libgd.org
From: ajf@ajf.me
Date: Sun, 14 Sep 2014 00:30:40 +0100
To: internals@lists.php.net
Subject: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with CastGood evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
https://wiki.php.net/rfc/scalar_type_hinting_with_cast#vote
Andrea Faulds
http://ajf.me/
RE: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with CastThomas Punt 11:23 To: Andrea Faulds> From: ajf@ajf.me
Date: Sun, 14 Sep 2014 00:30:40 +0100
To: internals@lists.php.net
Subject: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with CastGood evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
https://wiki.php.net/rfc/scalar_type_hinting_with_cast#vote
Andrea Faulds
http://ajf.me/
From a user-land developer perspective, I really detest this feature being added into PHP. If PHP has features that will make it a stronger-typed language, then it will undoubtedly lose its loosely-typed and forgiving nature eventually. The evangelists for making PHP a strongly-typed language will boast of its benefits (which will have some truth, in all fairness), and this will only lead to the condemnation of PHP code that doesn't use these stricter language features (slowly converting PHP into a stricter language). This isn't the easy-going and generally-liked nature of the PHP language in any way. Whilst I can see there are benefits of making PHP stricter, I for one would rather keep PHP as a loosely-typed and forgiving language. After all, if I wanted to use a strongly-typed language for building websites, then I'd be using Java instead.
The only part of the discussion I liked on this topic was the ability to use explicit type casts as part of the function signature. Whilst it is a bit of a syntactic sugar (which will cut out on some PHP code in the function body too), it does give the function parameters some sort of signature that will show their expected set of values (assuming developers know the casting rules, of course).
-Tom
(P.s sorry for the double email Andrea, I accidentally sent this to you only the first time...)
Hi Andrea,
When you re-open the voting, please can you have an option that is
'Yes - without numeric typehint' ?
Although I like the idea of the RFC, having a type-hint that matches
multiple scalar types seems distinctly weird to me.
It really needs a separate case making for it, separate from the
'should we have scalar type hints for the current types' question.
cheers
Dan
Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is after all a compromise proposal. However, I have tried my best to strike a balance between complete weak typing and strict typing. If this passes, we will finally have userland type specifiers for scalar types. It’s not perfect, but I’d argue it’s far better than nothing.
Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
https://wiki.php.net/rfc/scalar_type_hinting_with_cast#vote
Andrea Faulds
http://ajf.me/
When you re-open the voting, please can you have an option that is
'Yes - without numeric typehint’ ?
I was already planning that, actually. :)
Although I like the idea of the RFC, having a type-hint that matches
multiple scalar types seems distinctly weird to me.It really needs a separate case making for it, separate from the
'should we have scalar type hints for the current types' question.
Yeah. While me and Anthony thought it was a no-brainer, I’ve since seen some opposition to it, so I’d have its own vote.
Andrea Faulds
http://ajf.me/
Hello Andrea,
I find the rfc a bit difficult to understand:
e.g. is_float('1') gives false, but foo('1') with function foo(float $a){} is ok.
Regards,
Thomas
Andrea Faulds wrote on 14.09.2014 01:30:
Good evening,
I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
I would urge you to vote in favour. It is not going to please everyone, it is
after all a compromise proposal. However, I have tried my best to strike a
balance between complete weak typing and strict typing. If this passes, we will
finally have userland type specifiers for scalar types. It’s not perfect, but
I’d argue it’s far better than nothing.Voting starts today, 2014-09-14, and ends in a week’s time, 2014-09-21.
Thanks!
https://wiki.php.net/rfc/scalar_type_hinting_with_cast#vote
Andrea Faulds
http://ajf.me/
Am 14.09.2014 um 01:30 schrieb Andrea Faulds:
If I understand the "Syntax" section correctly, then int, float, numeric,
bool, and string are added as new reserved words (keywords). This would
break existing code, for instance userland classes named "String".
However, looking at the patch in http://bit.ly/1uADQnD I do not see
an addition of new tokens. So maybe there is no problem at all.
In any case, I think it would be best to build on the great work Nikita
did with the AST-based parser for PHP 7 and refactor the compiler to
allow reserved words as names for namespaces, classes, interfaces, ...
before we introduce new reserved words (and thus BC breaks).
Am 14.09.2014 um 01:30 schrieb Andrea Faulds:
If I understand the "Syntax" section correctly, then int, float, numeric,
bool, and string are added as new reserved words (keywords). This would
break existing code, for instance userland classes named "String".However, looking at the patch in http://bit.ly/1uADQnD I do not see
an addition of new tokens. So maybe there is no problem at all.
Why are you looking at the initial commit from two years ago? Many, many changes have been made since then. Did you not look at the branch?
Anyhow, this RFC is withdrawn, so there’s little point commenting on it further.
Andrea Faulds
http://ajf.me/
Sebastian Bergmann wrote (on 15/09/2014):
In any case, I think it would be best to build on the great work Nikita
did with the AST-based parser for PHP 7 and refactor the compiler to
allow reserved words as names for namespaces, classes, interfaces, ...
before we introduce new reserved words (and thus BC breaks).
Surely, in this case, the reserved word would have to be banned as a
class/interface name anyway, even if the parser generally allowed
reserved words there?
Otherwise the following is ambiguous:
class Int {
public function test(int $foo) {
// Is this function requiring an instance of class Int, or a
scalar of type int?
}
}
If the interpretation is as a class name, then defining that class
breaks all instances of scalar hinting everywhere in the current
execution. Not to mention how it would interact with autoloading,
reinterpreting already compiled functions, etc.
If the interpretation is as an int, then the BC break exists anyway,
because the keyword has to be "partially reserved", which is probably
more confusing than just reserving it.
I'm all for keeping the number of reserved words in a language down (cf
Douglas Crockford on why JSON requires quoting on all key names), but it
makes things very messy if you try not to have any at all.
Rowan Collins
[IMSoP]