Re: [PHP-DEV] Language specification patches in RFCs
Am 14.09.2014 um 22:41 schrieb Andrea Faulds: > Given PHP now has a (admittedly work-in-progress) language specification, > would it be reasonable to make an RFC to amend the current rules, such > that RFCs that change the language must include a patch to the > specification? +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4.33 RC1 => mod_proxy_fcgi still broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 11/09/2014 09:19, Remi Collet a écrit : > Le 11/09/2014 09:16, Remi Collet a écrit : >> Le 09/09/2014 07:54, Stas Malyshev a écrit : The big issue I >> see, is the news entry: > >> . Fixed #65641 (PHP-FPM incorrectly defines the SCRIPT_NAME >> variable when using Apache). (David Zuelke) > > Should probably be: > > . Fixed #67606 (FPM with mod_fastcgi/apache2.4 is broken) I fixed the NEW entry in 5.4: 2775dc2b443fc8abc3ae0a659c3a8a800ab90035 5.5: 6dc6daf7e33524531e429ea0ac8b2ecfd9325122 Can you please cherry-pick this in 5.4.33 / 5.5.17 before the release ? I plan to apply the patch for 65641 later in 5.5+ so for 5.5.17, 5.6.2, as this one really need tests and don't want to break anything else... Remi -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlQWiUAACgkQYUppBSnxahiukACg6YuLevbuZQw7/LjWNCgmub+L KzgAoOrZ8QUwjZZULKh68nCIxwQzgMOx =UvXq -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecated functions
Hi!
> The above are, as far as I’m concerned, all potential candidates for
> removal in PHP 7, so in order to reliably test a deprecated function
> I would suggest introducing a hidden function with this signature:
>
> void __deprecated__() { }
>
> And mark that function as eternally deprecated using the
> ZEND_ACC_DEPRECATED flag.
If this is needed only for testing, this should only be enabled with
ZEND_DEBUG flag active. Like leak() one.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Concurrency support for run-tests
On 15 Sep 2014 05:59, "Matt Ficken" wrote: > > In making/merging major changes (like concurrency) the most important thing is to not break that compatibility and dependability: > > Your patch will fail without the /proc filesystem(mac osx?). On Windows, you can check the %NUMBER_OF_PROCESSORS% environment variable. For unices that don't have /proc there may not be a single simple way to check. It won't "fail", it just wouldn't enable reasonable concurrency by default. But auto-enabling concurrency is out of question now anyway. While the patch looks big, most of it is caused by indentation, because some code was converted to a callback. > > For more speed, rather than grouping all, fe open_basedir tests into a single `Concurrency Group` its better to have them all operate in separate temporary directories and database tables (then you could run 32 or 64 openbase dir tests at once). Sure, I tried to unfuck the open_basedir tests, but failed once. Ps: Have to look at PFTT yet.
Re: [PHP-DEV] Concurrency support for run-tests
When building PFTT, the PHP Full Test Tool, one goal was maximizing speed so that we would be more likely to frequently Fully test PHP (Full-coverage of many scenarios), and to do that I built it to run tests concurrently... Concurrent/parallel execution can cause breaks that otherwise work with normal serial execution, so definitely don't enable concurrency in run-tests by default. run-tests.php's two main benefits are that it supports running the huge library of 15k+pecl PHPTs (compatiblity) and its a lightweight tool so that anyone who just built PHP can run `make test` to test their build (whereas PFTT Is a heavyweight tool). In making/merging major changes (like concurrency) the most important thing is to not break that compatibility and dependability: Your patch will fail without the /proc filesystem(mac osx?). On Windows, you can check the %NUMBER_OF_PROCESSORS% environment variable. For unices that don't have /proc there may not be a single simple way to check. For better performance, PFTT runs a pool of 3 to 4 processes per CPU, when the processes finish quickly, it runs fewer and when they slow down (due to pending IO ops), it runs more processes. See: http://git.php.net/?p=pftt2.git;a=blob;f=src/com/mostc/pftt/scenario/CLIScenario.java;h=30c81aabcb56698eebe4884d915298c92332b50d;hb=refs/heads/master#l61 and for other SAPI scenarios like Apache it runs 2 or 3 processes, see: http://git.php.net/?p=pftt2.git;a=blob;f=src/com/mostc/pftt/scenario/ProductionWebServerScenario.java;h=d509bddda2b3756f05321ddc273600aeb38372be;hb=refs/heads/master For more speed, rather than grouping all, fe open_basedir tests into a single `Concurrency Group` its better to have them all operate in separate temporary directories and database tables (then you could run 32 or 64 openbase dir tests at once). The ext/standard/tests/file and ext/mysql* PHPTs take the longest to run and mostly do IO operations so they benefit the most from maximizing concurrency. For databases, PFTT will create a new database (and for phpunit tests populate the database) for each test runner thread, See: http://git.php.net/?p=pftt2.git;a=blob;f=src/com/mostc/pftt/scenario/MySQLScenario.java;h=f768f58c4494cb2705a571ece22d533bfdc15192;hb=refs/heads/master#l164 On Wed, Sep 10, 2014 at 3:36 AM, Michael Wallner wrote: > On 09/07/14 22:00, Stas Malyshev wrote: > > Hi! > > > >> Having thought a bit about the subject, the heuristic I came up with > was to > >> 1) do not run tests from the same extension in parallel, and 2) do not > run > >> tests from certain extensions in parallel (e.g., mysql and pdo_mysql). > > > > How about making it a whitelist? For tests/extensions we know it's easy > > to paralellize (like ones not having external dependencies/servers/etc) > > simple script could whitelist a lot of them. For those more tricky, we > > could whitelist them gradually. > > > > So how about adding the concurrency switch, but leaving it disabled by > default? > > -- > Regards, > Mike > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
[PHP-DEV] Re: [VOTE] Removing Multiple Default Clauses in Switch Statements
On Sun, Sep 14, 2014 at 8:36 PM, Levi Morrison wrote: > On Fri, Sep 5, 2014 at 2:29 PM, Levi Morrison wrote: >> Dear list, >> >> I have opened voting on this RFC: >> https://wiki.php.net/rfc/switch.default.multiple#vote >> >> The RFC is very short so I will not summarize it here. >> >> Voting will remain open for 10 days and will close on Monday, >> September the 15th. > > As a reminder, the vote will close sometime tomorrow evening (UTC-7). > Thank you to everyone who has voted so far. That was a bit too hast and was ambiguous; to clarify the vote closes sometime in the evening of on Monday, September the 15th, UTC-7. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Removing Multiple Default Clauses in Switch Statements
On Fri, Sep 5, 2014 at 2:29 PM, Levi Morrison wrote: > Dear list, > > I have opened voting on this RFC: > https://wiki.php.net/rfc/switch.default.multiple#vote > > The RFC is very short so I will not summarize it here. > > Voting will remain open for 10 days and will close on Monday, > September the 15th. As a reminder, the vote will close sometime tomorrow evening (UTC-7). Thank you to everyone who has voted so far. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sun, Sep 14, 2014 at 3:22 PM, Derick Rethans wrote:
> 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:
1) function f(int $a) { } == f( (int) $a); -- with NO notices
2) function f(int $a) {} means $a must be exactly type int -- or
recoverable error is thrown
3) 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14/09/2014 20:01, Pierre Joye wrote:
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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14/09/2014 21:22, Derick Rethans wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE][RFC] Integer Semantics
Good evening, This RFC has been put to a vote. It starts today (2014-09-14) and ends in a week’s time (2014-09-21). https://wiki.php.net/rfc/integer_semantics#vote Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Language specification patches in RFCs
Good evening, Given PHP now has a (admittedly work-in-progress) language specification, would it be reasonable to make an RFC to amend the current rules, such that RFCs that change the language must include a patch to the specification? Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 21:22, Derick Rethans wrote:
> 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sun, 14 Sep 2014, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 13:17, Zeev Suraski wrote:
>
> > 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
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/
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sep 14, 2014 8:21 PM, "Rowan Collins" wrote: > 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.
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14/09/2014 17:41, Andrey Andreev wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 18:34, Stas Malyshev wrote: > 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. The section now says "For points I'm unsure on, this section lists possible future changes to the RFC.”. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 18:29, Stas Malyshev wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fix list() behavior inconsistency
On 14/09/2014 08:54, Lester Caine wrote: One has to assume first that what is returned is a simple byte string array while currently is IS possible that it will contain unicode characters? Well, currently, every single string function in PHP treats a string as a simple byte array, apart from those in the mbstring and intl extensions. What's more, there isn't really a single meaning of the term "Unicode character" - at its simplest, there are code points, but they're not necessarily the most useful unit; as I mentioned before [1], people often actually want to work with "grapheme clusters", what a writer of the language would consider "a single character". If more integrated Unicode support is ever added, it will presumably be in the form of a new data type; if that type implements $foo[0] to mean "first grapheme cluster", then it would be natural for list($a,) = $foo to do the same. But there is no reason for that to stop list($a,) = $foo being equivalent to $foo[0] for existing strings, and mean "first byte". [1] http://news.php.net/php.internals/72914 -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 18:23, Dan Ackroyd wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
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 On 14 September 2014 00:30, Andrea Faulds wrote: > 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/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sun, Sep 14, 2014 at 7:17 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 17:09, Andrey Andreev wrote:
>
>> 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.
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 17:09, Andrey Andreev wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds wrote: > > On 14 Sep 2014, at 16:40, Andrey Andreev wrote: > >> ... 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 internal*s*, 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 16:40, Andrey Andreev wrote: > ... 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 internal*s*, 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
Hi,
On Sun, Sep 14, 2014 at 6:09 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
>
>> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
> 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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On 14 Sep 2014, at 13:17, Zeev Suraski wrote: > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
> -Original Message- > From: Andrea Faulds [mailto:a...@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 Cast > > > 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
> On 14 Sep 2014, at 07:32, Stas Malyshev wrote: > > 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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
> From: a...@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 Cast > > 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/ > > RE: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with CastThomas Punt 11:23 To: Andrea Faulds> From: a...@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 Cast > > 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/ > > >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...)> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sun, Sep 14, 2014 at 11:12 AM, Alain Williams wrote: > On Sun, Sep 14, 2014 at 01:10:20AM +0100, Andrea Faulds wrote: >> >> On 14 Sep 2014, at 01:07, Alain Williams wrote: >> >> > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
On Sun, Sep 14, 2014 at 01:10:20AM +0100, Andrea Faulds wrote: > > On 14 Sep 2014, at 01:07, Alain Williams wrote: > > > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
hi Andrea, On Sun, Sep 14, 2014 at 1:30 AM, Andrea Faulds wrote: > 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Fix list() behavior inconsistency
On 14/09/14 07:48, Stas Malyshev wrote: >> Please take a look and make your opinion. >> > >> > https://wiki.php.net/rfc/fix_list_behavior_inconsistency >> > >> > This inconsistency might be interpreted like a bug, but fixing it might >> > break existing PHP code (at least my attempt to fix it in documented way >> > broke few phpt tests). > I think it makes sense to make list($a, $b, ...) = to mean: > $a = [0] > $b = [1] > ...etc... > > This is how it works in most cases, not sure why it doesn't work when > is a string literal, but I think it should work the same too. Isn't this just a side affect of making a simple string also look like an array? One has to assume first that what is returned is a simple byte string array while currently is IS possible that it will contain unicode characters? So should it not be looked at n the context of the whole PHP7 discussion rather than trying to fix more edge cases in isolation? -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
