Hi,
On Mon, February 2, 2015 20:15, Nikita Popov wrote:
On Mon, Feb 2, 2015 at 8:11 PM, Anatol Belski anatol@belski.net
wrote:
Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The
Hi,
I gave my votes (where I can talk about). I am still maintaining the NSAPI
SAPI. It does not meant that its dead if no commits were made. NSAPI upstream
API just did not change since years, so why change a running system?
The current version of this SAPI (5.6) runs perfectly with MediaWiki
Hi Dmitry,
On 2 Feb 2015, at 20:43, Dmitry Stogov dmi...@zend.com wrote:
I don't think we will implement strict semantic for operators.
It's not going to be PHP anymore
$s = (string)$a . (string)$b;
There’s no need either: operators always produce a specific type (or one of a
set of
Thomas Bley wrote:
Here is a typical billing example which uses exceptions:
?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
addVat('apples');
function addVat($amount) {
if (!is_int($amount) !is_float($amount)) {
throw new
Hi!
I see you've added test for #61470 to 5.5 and up. But this test is
failing on CI. Could you please look into it and fix it or revert it
until it works?
Thanks,
--
Stas Malyshev
smalys...@gmail.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On 02/02/15 21:17, Christoph Becker wrote:
Instead of multiple strict scalar hints (e.g. function addVat(int|float
$amount){...}), I would prefer to have numeric as strict type:
function addVat(numeric $amount){...}
Have you considered
addVat(-1);
Also addVat(1.235); which will be
-Ursprüngliche Nachricht-
Von: Dmitry Stogov [mailto:dmi...@zend.com]
Gesendet: Montag, 2. Februar 2015 20:14
An: Robert Stoll
Cc: PHP Internals; Andrea Faulds; Nikita Popov
Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
On Mon, Feb 2, 2015 at 9:41 PM, Robert
2015-02-02 11:12 GMT+02:00 Dmitry Stogov dmi...@zend.com:
hi,
could you please write down few use cases, when strict scalar type hints
are really useful.
Thanks. Dmitry.
Hello Dmitry,
At the moment, being a user-land dev for a little bit more than 10 years, I
just don't see the usage for
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.
Cheers,
Andrey.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Here is a typical billing example which uses exceptions:
?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
addVat('apples');
function addVat($amount) {
if (!is_int($amount) !is_float($amount)) {
throw new InvalidArgumentException('Argument 1 passed to '.__FUNCTION__.'
Hi Dmitry,
On 2 Feb 2015, at 19:26, Dmitry Stogov dmi...@zend.com wrote:
Agree. Strict type checks are simple and may be implemented more efficient.
But in case we have to support both - weak and strict, this won't make any
advantage.
I think this still works even if we support both. The
On 02/02/15 09:12, Dmitry Stogov wrote:
could you please write down few use cases, when strict scalar type hints
are really useful.
Do we NEED strict scalar type control ... No
Are there situations where strict scalar type control may be useful ...Yes
Can a library be built ONLY using strict
Hi,
On Mon, Feb 2, 2015 at 11:03 PM, Thomas Bley ma...@thomasbley.de wrote:
Here is a typical billing example which uses exceptions:
?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
addVat('apples');
function addVat($amount) {
if (!is_int($amount)
Yes, we currently have negative values for invoices and positive for vouchers
...
Christoph Becker wrote on 02.02.2015 22:17:
Thomas Bley wrote:
Here is a typical billing example which uses exceptions:
?php
ini_set('error_reporting', E_ALL);
ini_set('display_errors', 1);
Hi,
On Mon, February 2, 2015 22:39, Andrey Andreev wrote:
Hi,
On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski anatol@belski.net
wrote:
On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break.
On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd suggest
that instead of removal.
that sounds plausible, but the same one
On Mon, Feb 2, 2015 at 11:44 PM, Levi Morrison le...@php.net wrote:
Since it's been two weeks and there are no remaining issues (aside from the
lack of a language specification patch - but that can be done later), I'm
opening voting on this RFC.
I just noticed that you kept T_SPACESHIP;
On Feb 2, 2015 11:02 PM, Robert Stoll p...@tutteli.ch wrote:
-Ursprüngliche Nachricht-
Von: Dmitry Stogov [mailto:dmi...@zend.com]
Gesendet: Montag, 2. Februar 2015 20:14
An: Robert Stoll
Cc: PHP Internals; Andrea Faulds; Nikita Popov
Betreff: Re: [PHP-DEV] What do we need
On 02/02/15 20:15, Robert Stoll wrote:
Nobody would stop you from implementing a utility class Money or likewise and
providing a better error message instead of using int if PHP would be strict
only (what is not proposed in the RFC anyway). You could also just omit the
type hint, it is
Hi,
On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski anatol@belski.net wrote:
On Mon, February 2, 2015 20:30, Andrey Andreev wrote:
Oh, forgot one thing ...
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl -
Thomas Bley wrote:
Yes, we currently have negative values for invoices and positive for vouchers
...
Christoph Becker wrote on 02.02.2015 22:17:
Thomas Bley wrote:
Here is a typical billing example which uses exceptions:
?php
ini_set('error_reporting', E_ALL);
Hi Danack,
On 2 Feb 2015, at 22:50, Dan Ackroyd dan...@basereality.com wrote:
On 2 February 2015 at 19:11, Anatol Belski anatol@belski.net wrote:
The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting
On 02/02/15 23:05, Andrea Faulds wrote:
I’m a little worried that nobody has responded to this yet. Feature freeze is
looming… :(
Andrea ... I am still unhappy that this is being pushed as the core
'integer' handling. Further options have appeared for 32bit devices
which are driving me to
Hi Lester,
On 2 Feb 2015, at 23:46, Lester Caine les...@lsces.co.uk wrote:
Andrea ... I am still unhappy that this is being pushed as the core
'integer' handling. Further options have appeared for 32bit devices
which are driving me to seriously consider perhaps having to look into a
simple
Hello,
I personally would use spaceship operator often, but only if PHP had
operator overloading for classes. So I hope it will pass and operator
overloading will pass someday as well (but operator overloading would
probably require method overloading first and that's a thing you guys
oppose,
Hi again,
On 2 Feb 2015, at 23:34, Christoph Becker cmbecke...@gmx.de wrote:
Indeed, code is read far more often than it's written (hopefully :)),
but still it might be annoying for many PHP programmers to write these
explicit manual conversions in the first place.[2]
Well, they only have
Hi,
On Tue, Feb 3, 2015 at 12:16 AM, Anatol Belski anatol@belski.net wrote:
Mcrypt might be dead, but removing it would be a huge BC break. There
was some talk of binding mcrypt_*() functions to ext/openssl - I'd
suggest that instead of removal.
that sounds plausible, but the same one
Hi Andrea,
Andrea Faulds wrote:
Hi Christoph,
On 2 Feb 2015, at 22:38, Christoph Becker cmbecke...@gmx.de wrote:
And frankly, I don't see what's wrong with a weak type hint in this case:
function addVat(float $amount) {...}
You're returning a float, anyway.
Given you’re dealing
Hi Andrea,
On Mon, February 2, 2015 23:54, Andrea Faulds wrote:
Hi Danack,
On 2 Feb 2015, at 22:50, Dan Ackroyd dan...@basereality.com wrote:
On 2 February 2015 at 19:11, Anatol Belski anatol@belski.net
wrote:
The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously
Hi!
I personally would use spaceship operator often, but only if PHP had
operator overloading for classes. So I hope it will pass and operator
PHP has operator overloading for classes, but just for internal ones.
See: https://wiki.php.net/rfc/operator_overloading_gmp
For userspace ones, the
Hi,
On 28 Jan 2015, at 01:43, Andrea Faulds a...@ajf.me wrote:
Hey everyone,
Anatol (aka welting) has done some excellent work, and a lot more extensions
now build on the bigint branch, even if not all of them are fully ported:
https://wiki.php.net/rfc/bigint#todo
This should mean
Hi,
I was testing few things today and I released one bug in the serialize
function. The serialize function returns a corrupted value when it is
serializing an object that contains a __sleep magic method and this method
return some key that are not string. Ie:
http://viper-7.com/EK16EV
If the
Hi Christoph,
On 2 Feb 2015, at 22:38, Christoph Becker cmbecke...@gmx.de wrote:
And frankly, I don't see what's wrong with a weak type hint in this case:
function addVat(float $amount) {...}
You're returning a float, anyway.
Given you’re dealing with currency, and given the fairly
On 2 February 2015 at 19:11, Anatol Belski anatol@belski.net wrote:
The voting ends on 2015-02-09 at 21:00 CET.
This is a ridiculously short voting period for a major decision.
Although the minimum voting time for an RFC is one week, that should
only be used in extremis.
The people affected
On Mon, Feb 2, 2015 at 1:06 PM, Andrea Faulds a...@ajf.me wrote:
Hi everyone,
Since it's been two weeks and there are no remaining issues (aside from
the lack of a language specification patch - but that can be done later),
I'm opening voting on this RFC.
Voting starts today (2015-02-02)
found and added, php-src :)
Thanks for your work!
On Mon, Feb 2, 2015 at 4:32 PM, Pierre Joye pierre@gmail.com wrote:
what is your handle?
On Mon, Feb 2, 2015 at 12:23 AM, Jakub Zelenka bu...@php.net wrote:
Hello,
I'd like to request src karma to merge recently accepted jsond to master
Hello Andrea,
On 02.02.15 00:49, Andrea Faulds wrote:
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Version 0.3 of the RFC can be found here:
what is your handle?
On Mon, Feb 2, 2015 at 12:23 AM, Jakub Zelenka bu...@php.net wrote:
Hello,
I'd like to request src karma to merge recently accepted jsond to master
and further maintain json extension and committing perf improvements into
it.
In addition I'd like to look to few other
Hey:
if no objections, I will commit it.. (no bc breaks, no handle
removing , only APIs change)
dmitry suggest we change zend_fetch_resource to
zend_verify_resource, I think it make sense.. will do it.
thanks
On Mon, Feb 2, 2015 at 1:34 PM, Xinchen Hui larue...@php.net wrote:
Hey:
I should have stated my intent more clearly in the original mail. I
would be targeting 5.5 and above for a core change, and would provide
a an extension to back-fill 5.3 and 5.4. I think people should be able
to use authenticated modes of operation _now_, not when PHP 7 is
released and / or when
On Mon, Feb 2, 2015 at 3:58 AM, Leigh lei...@gmail.com wrote:
On 2 February 2015 at 10:57, Leigh lei...@gmail.com wrote:
length (not sure how of
Not sure how often tag lengths aside from 16 are used.
According to documentation provided about the OCB mode of AES it says the
following:
On 2 February 2015 at 11:46, Jason Gerfen jason.ger...@gmail.com wrote:
According to documentation provided about the OCB mode of AES it says the
following:
Section 3: The scheme
The tag length is an integer τ ∈ [0 .. n]. ... As for the tag length, a
suggested default of τ = 64 is
Lester Caine wrote on 02/02/2015 09:19:
This is probably because I still don't understand objects, as I still
just consider them as arrays with a few more complex elements. I STILL
work on the basis that is I pass by reference, I can make modifications
to the data while if I don't I get a copy
Hi everyone,
Since it's been two weeks and there are no remaining issues (aside from the
lack of a language specification patch - but that can be done later), I'm
opening voting on this RFC.
Voting starts today (2015-02-02) and ends in two weeks' time (2015-02-16). As
this adds to the PHP
On 2 February 2015 at 10:57, Leigh lei...@gmail.com wrote:
length (not sure how of
Not sure how often tag lengths aside from 16 are used.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 1 February 2015 at 17:57, Jakub Zelenka bu...@php.net wrote:
Hey,
I have already implemented all of this in crypto ext (
https://github.com/bukka/php-crypto ) and also added support for streams
(e.g.
On 3 Feb 2015, at 3:49 am, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 02/02/2015 08:38 AM, François Laupretre wrote:
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or
I have similar opinion. Strict typing looks foreign for PHP.
I see, strict type hints may be useful.
Aspecially for testing and error detection, but anyaway, I'm not sure if
and how it should be enabled. Declare() is a working solution, but it's not
excelent.
Thanks. Dmitry.
On Feb 3, 2015 12:31 AM, François Laupretre franc...@tekwire.net wrote:
De : Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Doesn't this imply that path is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm
On Feb 3, 2015 7:59 AM, Pierre Joye pierre@gmail.com wrote:
On Feb 3, 2015 11:26 AM, Xinchen Hui larue...@php.net wrote:
Hey:
opcache is disabled by default configure, I am plan to enable it
by default
and also add zend_extension=opcache.so in
Hey:
opcache is disabled by default configure, I am plan to enable it
by default
and also add zend_extension=opcache.so in php.ini-product/developmement
is there any objections or concerns?
thanks
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP
On Feb 3, 2015 11:26 AM, Xinchen Hui larue...@php.net wrote:
Hey:
opcache is disabled by default configure, I am plan to enable it
by default
and also add zend_extension=opcache.so in
php.ini-product/developmement
is there any objections or concerns?
thanks
No problem
On 02.02.15 14:49, Nikita Popov wrote:
I've voted -1 because I think this should be a function and not an
operator. compare($a, $b) is more obvious than $a = $b and it's not like
writing comparison functions is such a super common use case that it needs
the extra brevity of an operator. A
On 2 February 2015 at 14:30, Daniel Lowrey rdlow...@php.net wrote:
The extra params aren't really _that_ bad.
Okay, I'd like to reset the conversation a bit here. It's clear that the
current API does not fit the problem domain very well. Tacking on more
parameters only creates a bigger mess.
Hey Nikita,
On 2 Feb 2015, at 13:49, Nikita Popov nikita@gmail.com wrote:
I've voted -1 because I think this should be a function and not an operator.
compare($a, $b) is more obvious than $a = $b and it's not like writing
comparison functions is such a super common use case that it
The extra params aren't really _that_ bad.
Okay, I'd like to reset the conversation a bit here. It's clear that the
current API does not fit the problem domain very well. Tacking on more
parameters only creates a bigger mess. Six parameters to a stateless
function call is a completely incoherent
On 3 Feb 2015 08:10, Adam Harvey ahar...@php.net wrote:
On 3 February 2015 at 03:11, Anatol Belski anatol@belski.net wrote:
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 03/02/2015 08:10, Adam Harvey a écrit :
To explain my -1s:
- ext/imap and ext/mcrypt: while I realise that the underlying
libraries are dead,
This means, if we want to keep them, we have to take ownership and
maintain those libraries.
Do
I want to add a link here to the Java article about Value Types, this
information is quite interesting:
http://cr.openjdk.java.net/~jrose/values/values-0.html
Probably, immutable value objects will be soon in Java world according to
this information:
Conclusion
Along with the questions, we
On 3 February 2015 at 03:11, Anatol Belski anatol@belski.net wrote:
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
To explain my -1s:
- ext/imap
Hi Dmitry,
On 2 Feb 2015, at 09:24, Dmitry Stogov dmi...@zend.com wrote:
Will we able to call the same function using weak
type hinting from on file and with strict from the other?
Yes, for the parameter type hints anyway. That means that strict and weak
code is interoperable without
De : Xinchen Hui [mailto:larue...@php.net]
furthermore, I'd like to discuss remove the handle in zend_resource struct..
it may breaks some usage (use resource as long/double/string)
case IS_RESOURCE: {
char buf[sizeof(Resource id #) + MAX_LENGTH_OF_LONG];
int
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As already said, we're just going around in circles at this point, but
a migration issue?
Whatever code using the scalar type hints should be *new* code in
userland.
Why not existing userland code? If only new
On Mon, Feb 2, 2015 at 8:27 AM, Andrea Faulds a...@ajf.me wrote:
Hey Nikita,
On 2 Feb 2015, at 13:49, Nikita Popov nikita@gmail.com wrote:
I've voted -1 because I think this should be a function and not an operator.
compare($a, $b) is more obvious than $a = $b and it's not like writing
On Mon, Feb 2, 2015 at 2:30 PM, Daniel Lowrey rdlow...@php.net wrote:
The extra params aren't really _that_ bad.
Okay, I'd like to reset the conversation a bit here. It's clear that the
current API does not fit the problem domain very well. Tacking on more
parameters only creates a bigger
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It changes type hinting behavior per file scope, so, just to try strict
type hinting in
Hi Dmitry,
It's preferred to have flexible scalars, that way we can interchange
between a numerical string or an integer.
Over defining on such things loses the powerfulness of PHP. So scalar
typehints are detrimental rather than useful. Saying something is a scalar
or not, is useful however! :)
Hi,
On Mon, Feb 2, 2015 at 6:39 PM, Andrea Faulds a...@ajf.me wrote:
Hey Derick,
On 2 Feb 2015, at 16:35, Derick Rethans der...@php.net wrote:
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very
Hi Matthew,
On 2 Feb 2015, at 16:45, Matthew Leverton lever...@gmail.com wrote:
On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types
RFC has passed. The patch is a work in progress: it
Hi Andrey,
On 2 Feb 2015, at 16:57, Andrey Andreev n...@devilix.net wrote:
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As already said, we're just going around in circles at this point, but
On Mon, Feb 2, 2015 at 12:03 PM, Leigh lei...@gmail.com wrote:
In Rogaway's own OCB FAQ it states:
The number τ, the tag length of the scheme, is, like the blockcipher
E, a parameter of the mode. It’s a number 0 ≤ τ ≤ 128.
http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm
The OCB is
Hi,
On Mon, Feb 2, 2015 at 6:17 PM, Andrea Faulds a...@ajf.me wrote:
Hi Markus,
On 2 Feb 2015, at 14:25, Markus Fischer mar...@fischer.name wrote:
- Since consensus on the strict mode does part the community (or, the
greater community also outside @internals) my impression is that the
On Mon, Feb 2, 2015 at 4:27 PM, Andrea Faulds a...@ajf.me wrote:
Hey Nikita,
On 2 Feb 2015, at 13:49, Nikita Popov nikita@gmail.com wrote:
I've voted -1 because I think this should be a function and not an
operator. compare($a, $b) is more obvious than $a = $b and it's not like
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.
Cheers
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds a...@ajf.me wrote:
Good evening,
The RFC has been updated to cover return types, since Levi’s Return Types RFC
has passed. The patch is a work in progress: it works, but lacks tests for
return types.
Version 0.3 of the RFC can be found here:
On 02/02/2015 08:38 AM, François Laupretre wrote:
Hi,
Opening the vote for :
https://wiki.php.net/rfc/streams-is-cacheable
This RFC proposes a generic way for opcode caches to decide if a given URI
is cacheable or not.
Doesn't this imply that path is the one true cache key? There are
A use case would be where scalar type hints are detrimental are:
I implement an API that returns integers for entity ids, like 2,3,4,5,6.
and my web-frontend handles this fine because it's a scalar. Then, you want
to convert entity ids to UUID. This would break your entire web frontend
Hi,
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As already said, we're just going around in circles at this point, but
a migration issue?
Whatever code using the scalar type hints should be
Hi Markus,
On 2 Feb 2015, at 14:25, Markus Fischer mar...@fischer.name wrote:
- Since consensus on the strict mode does part the community (or, the
greater community also outside @internals) my impression is that the
current best way to move forward would be
- get the rfc to only go for
Hey Nikita,
On 2 Feb 2015, at 16:32, Nikita Popov nikita@gmail.com wrote:
On Mon, Feb 2, 2015 at 4:27 PM, Andrea Faulds a...@ajf.me wrote:
Hey Nikita,
On 2 Feb 2015, at 13:49, Nikita Popov nikita@gmail.com wrote:
I've voted -1 because I think this should be a function and not
Hey Derick,
On 2 Feb 2015, at 16:35, Derick Rethans der...@php.net wrote:
On Mon, 2 Feb 2015, Dmitry Stogov wrote:
As I already told, in my opinion, version 0.1 was the perfect solution that
fit into PHP semantic very well.
declare(strict_types=1); - is really weird solution.
It
Since it's been two weeks and there are no remaining issues (aside from the
lack of a language specification patch - but that can be done later), I'm
opening voting on this RFC.
I just noticed that you kept T_SPACESHIP; while that is fun I don't
think it is appropriate. It is a common name
Hi,
Opening the vote for :
https://wiki.php.net/rfc/cyclic-replace
This RFC adds support in str_replace() and str_ireplace() for the
combination of
(string needle, array replace). In this case, each occurrence of the needle
is replaced with an element of the 'replace' array.
Cheers
François
Hi Dimitry,
-Ursprüngliche Nachricht-
Von: Dmitry Stogov [mailto:dmi...@zend.com]
Gesendet: Montag, 2. Februar 2015 10:13
An: PHP Internals; Andrea Faulds; Nikita Popov
Betreff: [PHP-DEV] What do we need strict scalar type hints for?
hi,
could you please write down few use
So, one of the advantages of strict type hinting is the ability to catch
potential errors.
For example when we pass 67 to setBody(string $message).
Thanks. Dmitry.
On Mon, Feb 2, 2015 at 7:30 PM, Andrea Faulds a...@ajf.me wrote:
Hi Dmitry,
On 2 Feb 2015, at 09:24, Dmitry Stogov
Hi!
Keeping that in mind, the declare statement, as ugly as it may look,
could be actually a killer to finally get what both camps want but
never (and never will) manage to agree.
I think having two conceptual frameworks in one language and having to
deal with (and potentially maintain) code
On Mon, Feb 2, 2015 at 9:05 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Mon, Feb 2, 2015 at 4:12 PM, Dmitry Stogov dmi...@zend.com wrote:
hi,
could you please write down few use cases, when strict scalar type hints
are really useful.
I think there is one big misunderstanding
-Ursprüngliche Nachricht-
Von: Lester Caine [mailto:les...@lsces.co.uk]
Gesendet: Montag, 2. Februar 2015 21:06
An: internals@lists.php.net
Betreff: Re: [PHP-DEV] What do we need strict scalar type hints for?
On 02/02/15 09:12, Dmitry Stogov wrote:
could you please write down
Hi Uwe,
On Mon, February 2, 2015 21:20, Uwe Schindler wrote:
Hi,
I gave my votes (where I can talk about). I am still maintaining the
NSAPI
SAPI. It does not meant that its dead if no commits were made. NSAPI
upstream API just did not change since years, so why change a running
system?
Hi,
On Mon, February 2, 2015 20:11, Anatol Belski wrote:
Hi,
properly after the voting phase the
https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the
voting. Each item is voted separately. The voting ends on 2015-02-09 at
21:00 CET.
I have to resend this announcement,
Hey everyone,
On 2 Feb 2015, at 16:50, Andrea Faulds a...@ajf.me wrote:
The implementation does work for testing. I still need to write tests for
return types but they seem to work. Parameter types are fully-working,
though, and they have extensive tests, so I know they’re working fine
Hi,
On Mon, Feb 2, 2015 at 7:00 PM, François Laupretre franc...@tekwire.net wrote:
Hi,
Opening the vote for :
https://wiki.php.net/rfc/cyclic-replace
This RFC adds support in str_replace() and str_ireplace() for the
combination of
(string needle, array replace). In this case, each
De : Rasmus Lerdorf [mailto:ras...@lerdorf.com]
Doesn't this imply that path is the one true cache key? There are some
issues with that which we will have to address at some point. For
example, when running fpm chrooted you need more than the path. We'll
likely need a more APC-like option
hi,
On Mon, Feb 2, 2015 at 4:12 PM, Dmitry Stogov dmi...@zend.com wrote:
hi,
could you please write down few use cases, when strict scalar type hints
are really useful.
I think there is one big misunderstanding in Andrea's RFC.
Strictness is local only. Or to say it in a better way, only
On Mon, Feb 2, 2015 at 7:00 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:57, Andrey Andreev n...@devilix.net wrote:
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds a...@ajf.me wrote:
Hi Andrey,
On 2 Feb 2015, at 16:48, Andrey Andreev n...@devilix.net wrote:
As
On Tue, Dec 2, 2014 at 11:28 AM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 1 December 2014 22:28:04 GMT, Ralph Schindler
ra...@ralphschindler.com wrote:
Hi all,
Many of you know from reading the subject line
I missed the discussion on this entirely. I see it took place in a
non-obvious thread, in which Nikita asked:
On 10 January 2015 at 11:53, Nikita Popov nikita@gmail.com wrote:
When submitting an RFC, please open a separate thread. Otherwise people who
do not follow every single discussion
On 2 February 2015 at 17:00, François Laupretre franc...@tekwire.net wrote:
Hi,
Opening the vote for :
https://wiki.php.net/rfc/cyclic-replace
This RFC adds support in str_replace() and str_ireplace() for the
combination of
(string needle, array replace). In this case, each occurrence of
De : Andrey Andreev [mailto:n...@devilix.net]
I seem to have missed the new parameter (and constants) addition
during the discussion ... sorry to say this, but that one would
probably fail the RFC.
Mmh... I don't like the idea of adding a parameter but several people argued
that we needed a
On Mon, Feb 02, 2015 at 05:00:08PM +, Andrea Faulds wrote:
Hi Andrey,
...
Just to give thanks to Andrea on persisting with a highly contentious RFC, one
that has defeated several others over the years. I hope that we will end up with
something acceptable to most and will be able to finally
1 - 100 of 129 matches
Mail list logo
