On 15/07/14 06:17, Stas Malyshev wrote:
Both of those are likely not to be installed on most systems. Why do
Why not? bcmath is in core since forever and has no external
requirements, gmp builds practically everywhere too. AFAIR all distros
have it.
Taking this in isolation is wrong ...
It is
On Mon, 14 Jul 2014, Stas Malyshev wrote:
In general, I am not in favour of casting typehints, as it would be
a different behaviour from the hard-check typehints that we already
have for classes and arrays.
It already is. All internal functions behave this way.
But casting typehints
On Mon, 14 Jul 2014, Rowan Collins wrote:
Derick Rethans wrote (on 14/07/2014):
A compromise by adding more inconsistencies.
The only way of not introducing some inconsistencies (or, to put it another
way, new features) is to use strict type hints, which perform no casting, and
error on
-Original Message-
From: Stas Malyshev [mailto:smalys...@sugarcrm.com]
Sent: Tuesday, July 15, 2014 2:00 AM
To: Andrea Faulds; Chris Wright
Cc: PHP internals
Subject: Re: [PHP-DEV] [RFC] Scalar Type Hinting With Casts (re-opening)
Hi!
I suggested on IRC that empty strings, TRUE,
On 15 Jul 2014, at 03:31, Bishop Bettini bis...@php.net wrote:
I need some education. Can you elaborate on the specific situations where
integer division would be used without other functions from bcmath or gmp?
I see in the RFC you mention seconds to hh:mm and index to rows/cols, but can
Oh, goodness, deary me -- this sounded so familiar I just had to do some
delving and hey presto! I refer you to:
http://marc.info/?l=php-internalsm=124655821522388
(...which, interestingly, even predates Zeev's 2010 claim, and I believe may
have taken inspiration from yet earlier suggestions
On 15 Jul 2014, at 06:50, Kris Craig kris.cr...@gmail.com wrote:
While a practical argument can certainly be made that existing solutions can
fit the examples OP cited, I don't think that takes away from the underlying
principle of the argument: That there's no reason *not* to include a
On 15 Jul 2014, at 08:06, Lester Caine les...@lsces.co.uk wrote:
Taking this in isolation is wrong ...
It is essentially linked up with all of the discussion on '64bit'
processing. What seems to be ignored so far is the simple 'bigint'
value. Limiting 32 bit systems to only support 32 bit
On Mon, Jul 14, 2014 at 7:19 PM, Kristopher kristopherwil...@gmail.com
wrote:
On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams a...@phcomp.co.uk wrote:
On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
On 14 Jul 2014, at 18:01, Alain Williams a...@phcomp.co.uk wrote:
On 15 Jul 2014, at 06:17, Stas Malyshev smalys...@sugarcrm.com wrote:
Why not? bcmath is in core since forever and has no external
requirements, gmp builds practically everywhere too. AFAIR all distros
have it.
Partly practicality, partly principle. A barebones installation of PHP may not
On Tue, Jul 15, 2014 at 2:19 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Mon, Jul 14, 2014 at 7:19 PM, Kristopher kristopherwil...@gmail.com
wrote:
On Mon, Jul 14, 2014 at 1:14 PM, Alain Williams a...@phcomp.co.uk
wrote:
On Mon, Jul 14, 2014 at 06:09:22PM +0100, Andrea Faulds wrote:
On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:
But php doesn't care, because one of it's distinguished features is that it
can coerce between scalar types.
Yes: and you will still be able to do that. No one will take that away, so
continue to use that where it is appropriate.
On 15 Jul 2014, at 13:50, Alain Williams a...@phcomp.co.uk wrote:
It will blow up with a fat E_RECOVERABLE_ERROR.
But this won't hold back the library authors from using it, which means
that the consumers of those libs has to start coding defensively, and make
sure that the variable holding
On Tue, Jul 15, 2014 at 2:50 PM, Alain Williams a...@phcomp.co.uk wrote:
On Tue, Jul 15, 2014 at 02:19:46PM +0200, Ferenc Kovacs wrote:
But php doesn't care, because one of it's distinguished features is that
it
can coerce between scalar types.
Yes: and you will still be able to do that.
On 15 Jul 2014, at 14:18, Ferenc Kovacs tyr...@gmail.com wrote:
you can't optionally introduce strict typing to php, as the two of them
can't co-exists.
nobody forces you to not use a language with strict typing if you want
that, but I don't think that it would worth changing the php type
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
On 15 Jul 2014, at 14:18, Ferenc Kovacs tyr...@gmail.com wrote:
you can't optionally introduce strict typing to php, as the two of them
can't co-exists.
nobody forces you to not use a language with strict typing if you
Ferenc Kovacs wrote (on 15/07/2014):
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner) is a must.
Isn’t a must, surely? (I assume that was a typo)
I wasn't talking
On Tue, Jul 15, 2014 at 4:09 PM, Rowan Collins rowan.coll...@gmail.com
wrote:
Ferenc Kovacs wrote (on 15/07/2014):
On Tue, Jul 15, 2014 at 3:21 PM, Andrea Faulds a...@ajf.me wrote:
as I mentioned above, nobody argues that input validation (and escaping
output in a context sensitive manner)
Ferenc Kovacs wrote (on 15/07/2014):
sorry, not a native speaker.
No problem, I think the intention was clear enough, and certainly meant
no criticism. :)
so you are saying that nobody argues that $someGenericStatement is
not proper grammar?
in my case the $someGenericStatement was that
Stas Malyshev wrote (on 14/07/2014):
But I'm not sure why you need this. You accept that if(foo)
works. Then why function foo(bool $x) { if($x) { ... should work
differently?
The answer - which is definitely a matter of opinion - is that allowing
any string reduces the usefulness of the type
On 15 Jul 2014, at 15:28, Rowan Collins rowan.coll...@gmail.com wrote:
Stas Malyshev wrote (on 14/07/2014):
But I'm not sure why you need this. You accept that if(foo)
works. Then why function foo(bool $x) { if($x) { ... should work
differently?
The answer - which is definitely a matter
On Mon, Jul 14, 2014 at 11:16 PM, Park Framework
park.framew...@gmail.com wrote:
Maybe we should make two different syntax?
fun(int $num, array $list) - for strict type compliance
fun((int) $num, (array) $list) - converted to type
It will be very obvious, and without magic.
Hi!
On the other hand, this RFC proposes a set of type hint casts which
have stricter rules than an explicit cast, and also somewhat stricter
than zend_parse_parameters, meaning that people can safely do
$_GET[‘thing’] and it’ll work, but if a nonsensical value is passed
in, the program will
Hi!
The answer - which is definitely a matter of opinion - is that allowing
any string reduces the usefulness of the type hint.
IMO, having consistent rules is much more, orders of magnitude more
important than serving any particular use case. We will always have use
cases in which any
Stas Malyshev wrote (on 15/07/2014):
IMO, having consistent rules is much more, orders of magnitude more
important than serving any particular use case
We are adding a new feature to a language which is already inconsistent.
We can only make it consistent with one part of the language by
On 15 Jul 2014, at 18:24, Rowan Collins rowan.coll...@gmail.com wrote:
Stas Malyshev wrote (on 15/07/2014):
IMO, having consistent rules is much more, orders of magnitude more
important than serving any particular use case
We are adding a new feature to a language which is already
Stas Malyshev wrote (on 15/07/2014):
Having more than one set of rules
for implicit cast makes no sense to me at all and will only lead to
more confusion and frustrated users.
That's only a problem if you frame the new hints as a type of implicit
cast. If they were to be described in
Ford, Mike wrote (on 15/07/2014):
Oh, goodness, deary me -- this sounded so familiar I just had to do some delving
and hey presto! I refer you
to:http://marc.info/?l=php-internalsm=124655821522388
(...which, interestingly, even predates Zeev's 2010 claim, and I believe may
have taken
On 15 Jul 2014, at 18:39, Rowan Collins rowan.coll...@gmail.com wrote:
Ooh, skimming that, I see suggestions for prefixes and suffixes to represent
types of cast (or hint).
That fits nicely with my thoughts on making strict cast a first-class
citizen of the language, rather than
Andrea Faulds wrote (on 15/07/2014):
It’s a shame Nikita’s Exceptions in the Engine RFC failed, as being able to do
this would be nice:
try {
$foo = (int!)$foo;
} catch (RecoverableError) {
$foo = 1;
}
Perhaps some sort of similar syntax? `(int!)$foo else 0`?
I was thinking the
On Tue, Jul 15, 2014 at 8:24 PM, Rowan Collins rowan.coll...@gmail.com wrote:
The logical conclusion from that is not to have type hints at all. So far,
that is in fact the only consensus the PHP community has ever reached - not
to have scalar type hints.
I'm sorry, I know what you mean here
On 15 Jul 2014, at 19:59, Rowan Collins rowan.coll...@gmail.com wrote:
Or, to implement a safe cast, and catch the error case:
if ( false === $foo = filter_var($foo, FILTER_VALIDATE_INT) ) {
$foo = 1;
}
Yuck! :P
The patch and RFC introduce a new set of “safe” conversion functions
On 15 Jul 2014, at 20:43, Andrey Andreev n...@devilix.net wrote:
I'm sorry, I know what you mean here and I'm not criticizing you
specifically (in fact, I'm intentionally taking it ouf of context),
but that's PHP internals, not PHP community.
The PHP community that I know, wants to have
On Tue, Jul 15, 2014 at 10:48 PM, Andrea Faulds a...@ajf.me wrote:
On 15 Jul 2014, at 20:43, Andrey Andreev n...@devilix.net wrote:
I'm sorry, I know what you mean here and I'm not criticizing you
specifically (in fact, I'm intentionally taking it ouf of context),
but that's PHP internals,
On Tue, Jul 15, 2014 at 11:02 PM, Andrey Andreev n...@devilix.net wrote:
On Tue, Jul 15, 2014 at 10:48 PM, Andrea Faulds a...@ajf.me wrote:
On 15 Jul 2014, at 20:43, Andrey Andreev n...@devilix.net wrote:
I'm sorry, I know what you mean here and I'm not criticizing you
specifically (in fact,
On 15 Jul 2014, at 21:02, Andrey Andreev n...@devilix.net wrote:
Unless you really force the camps to pick one by saying you can't
have Y if we've got X (to which there's no technical limitation, so
that's not true)
No technical limitation, sure, but it would be really weird for PHP to go in
Hi!
The PHP community that I know, wants to have _both_ type cast hinting
and strict type declarations.
No, different members of the community want different options, because
it would serve their particular use cases. But that does not mean it
necessarily must be part of PHP - not all use
Hi!
That's only a problem if you frame the new hints as a type of implicit
cast. If they were to be described in relation to existing
functionality, I'd describe them as a new type of *explicit* cast, but
How they are explicit cast if you're not explicitly casing anything?
as mentioned
On 15 Jul 2014, at 22:02, Stas Malyshev smalys...@sugarcrm.com wrote:
That's exactly what I want to avoid - having several forms of casts with
different rules. One is good, two is kind of OK, three is too much.
Especially as you won't even know which rules something as simple as
foo($bar)
On 15 Jul 2014, at 22:08, Andrea Faulds a...@ajf.me wrote:
Also, sure, the scalar type hint behaviour is inconsistent with zpp in some
cases (booleans, 12.5, “12a”), but it’s inconsistent with most of it, and you
can describe what they do with a single sentence (“Scalar type hints will
Hi Andrea,
On Tue, Jul 15, 2014 at 11:10 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Tue, Jul 15, 2014 at 9:14 AM, Andrea Faulds a...@ajf.me wrote:
PHP currently lacks a way to do integer division. You can floor or int
cast a floating-point division, but beyond 53-bits that produces the
On 15 Jul 2014, at 23:12, Yasuo Ohgaki yohg...@ohgaki.net wrote:
If we are going to have integer arithmetics, it may be better to have full
set of operators/functions
https://bugs.php.net/bug.php?id=30701
I’d rather not go to that length, but if someone wants to do that, they may.
Hi all,
crypt() has BC issue with older systems.
https://bugs.php.net/bug.php?id=62372edit=1
The reason rounds became 1000 from 10 is hardcoded lower limit for newer
PHPs.
Generally speaking, developer should never use less than 1000 rounds and
better to have
at least few thousands rounds or
On 16 Jul 2014, at 01:46, Yasuo Ohgaki yohg...@ohgaki.net wrote:
- Developer may use larger rounds and store updated hash when
user is authenticated with old PHP.
- Developer may ask users to reset password if password hash has
to fewer rounds than 1000 (i.e. outdated hash) with new PHP.
On 16 Jul 2014, at 02:45, Yasuo Ohgaki yohg...@ohgaki.net wrote:
This change was done while ago, so it would not worth the effort to relax
the requirement now. IMHO.
We may add optional flag to relax the limitation, though.
I don't mind modifying crypt() or adding migration INI setting.
Hi Andrea,
TL;DR -- I agree with the principal but want implemented as the infix
operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING).
As a user, I could implement intdiv and get the same functionality as
proposed:
function intdiv($n, $d) { return (int)($n / $d); }
Hi Andrea,
On Wed, Jul 16, 2014 at 10:47 AM, Andrea Faulds a...@ajf.me wrote:
This change was done while ago, so it would not worth the effort to relax
the requirement now. IMHO.
We may add optional flag to relax the limitation, though.
I don't mind modifying crypt() or adding
On 16 Jul 2014, at 02:51, Bishop Bettini bis...@php.net wrote:
Hi Andrea,
TL;DR -- I agree with the principal but want implemented as the infix
operator %% with a test for PHP_INT_MIN %% -1 === false (and a E_WARNING).
%% is perhaps the only good non-keyword syntax choice. I like that.
Hi all,
There are few places that uses php_rand() currently.
https://bugs.php.net/bug.php?id=66718
http://lxr.php.net/search?q=php_randdefs=refs=path=hist=project=PHP_5_5
These functions could use php_mt_rand() instead of php_rand().
php_rand() uses several rand functions
62PHPAPI long
49 matches
Mail list logo
