-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
On 3 Feb 2015 08:10, "Adam Harvey" wrote:
>
> On 3 February 2015 at 03:11, Anatol Belski 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 CE
On 3 February 2015 at 03:11, Anatol Belski 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 and ext/mcrypt: whil
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 Feb 3, 2015 12:31 AM, "François Laupretre" 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 chrooted you n
On Feb 3, 2015 7:59 AM, "Pierre Joye" wrote:
>
> On Feb 3, 2015 11:26 AM, "Xinchen Hui" 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
> >
> >
On Feb 3, 2015 11:26 AM, "Xinchen Hui" 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 her
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 Run
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 3 Feb 2015, at 3:49 am, Rasmus Lerdorf 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 o
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 Andrea,
On Mon, February 2, 2015 23:54, Andrea Faulds wrote:
> Hi Danack,
>
>
>> On 2 Feb 2015, at 22:50, Dan Ackroyd wrote:
>>
>>
>> On 2 February 2015 at 19:11, Anatol Belski
>> wrote:
>>
>>> The voting ends on 2015-02-09 at 21:00 CET.
>>>
>>
>> This is a ridiculously short voting period fo
Hi again,
> On 2 Feb 2015, at 23:34, Christoph Becker 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 to if they ch
Hi Lester,
> On 2 Feb 2015, at 23:46, Lester Caine 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 64bit maths
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 ser
Hi Andrea,
Andrea Faulds wrote:
> Hi Christoph,
>
>> On 2 Feb 2015, at 22:38, Christoph Becker 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 wit
Hi,
> On 28 Jan 2015, at 01:43, Andrea Faulds 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 th
Hi Danack,
> On 2 Feb 2015, at 22:50, Dan Ackroyd wrote:
>
> On 2 February 2015 at 19:11, Anatol Belski 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 sho
Hi Christoph,
> On 2 Feb 2015, at 22:38, Christoph Becker 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 serious issue
On 2 February 2015 at 19:11, Anatol Belski 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 by this decision are
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 Tue, Feb 3, 2015 at 12:16 AM, Anatol Belski 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
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:
>>>
>>> >> ini_set('error_reporting', E_ALL);
>>> i
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, righ
2015-02-02 11:12 GMT+02:00 Dmitry Stogov :
> 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 the stri
Hi,
On Mon, February 2, 2015 22:39, Andrey Andreev wrote:
> Hi,
>
>
> On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski
> 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. T
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:
>>
>> > ini_set('error_reporting', E_ALL);
>> ini_set('display_errors', 1);
>>
>> a
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 w
Hey everyone,
> On 2 Feb 2015, at 16:50, Andrea Faulds 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 and you
Hi,
On Mon, Feb 2, 2015 at 9:45 PM, Anatol Belski 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 - I'd suggest
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 announceme
Hi,
On Mon, Feb 2, 2015 at 11:03 PM, Thomas Bley wrote:
> Here is a typical billing example which uses exceptions:
>
> ini_set('error_reporting', E_ALL);
> ini_set('display_errors', 1);
>
> addVat('apples');
>
> function addVat($amount) {
> if (!is_int($amount) && !is_float($amount)) {
> t
Thomas Bley wrote:
> Here is a typical billing example which uses exceptions:
>
> 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('
Here is a typical billing example which uses exceptions:
hi,
>
> could you please write down few use cases, when strict scalar type hints
> are really useful.
>
> Thanks. Dmitry.
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 e
Hi Dmitry,
> On 2 Feb 2015, at 20:43, Dmitry Stogov 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 types) so it
On Feb 2, 2015 11:02 PM, "Robert Stoll" 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 stri
On Mon, Feb 2, 2015 at 11:44 PM, Levi Morrison 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; while tha
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
> sys
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
> -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
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 s
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: http://www.php
> -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,
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
Hi,
On Mon, February 2, 2015 20:15, Nikita Popov wrote:
> On Mon, Feb 2, 2015 at 8:11 PM, 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 end
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: http:
Hi Dmitry,
> On 2 Feb 2015, at 19:26, Dmitry Stogov 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 RFC’s appro
Hi,
On Mon, Feb 2, 2015 at 9:15 PM, Nikita Popov wrote:
> On Mon, Feb 2, 2015 at 8:11 PM, 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 2
On Mon, Feb 2, 2015 at 10:12 PM, Andrea Faulds wrote:
> Hi Dmitry,
>
> > On 2 Feb 2015, at 18:22, Dmitry Stogov wrote:
> >
> > 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).
>
> Yes, that s
2015-02-02 21:12 GMT+02:00 Andrea Faulds :
> Hi Dmitry,
>
>> On 2 Feb 2015, at 18:22, Dmitry Stogov wrote:
>>
>> 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).
>
> Yes, that sort of thing is
On 02/02/15 19:11, Anatol Belski 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.
I feel this is totally out of line since only people who use m
On 02/02/2015 18:56, Stanislav Malyshev wrote:
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 havin
On Mon, Feb 2, 2015 at 8:11 PM, 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.
>
> Regards
>
> Anatol
>
I get the moti
On Mon, Feb 2, 2015 at 9:41 PM, Robert Stoll wrote:
> 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 sc
Hi Dmitry,
> On 2 Feb 2015, at 18:22, Dmitry Stogov wrote:
>
> 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).
Yes, that sort of thing is easily caught by strict type checks. They’re also
a
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.
Regards
Anatol
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://w
Hi Stas,
> On 2 Feb 2015, at 18:56, Stanislav Malyshev wrote:
>
> 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 fra
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) cod
On Mon, Feb 2, 2015 at 9:05 PM, Pierre Joye wrote:
> hi,
>
> On Mon, Feb 2, 2015 at 4:12 PM, Dmitry Stogov 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.
>
> Str
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
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 wrote:
> Hi Dmitry,
>
> > On 2 Feb 2015, at 09:24, Dmitry Stogov wrote:
> >
> > > W
hi,
On Mon, Feb 2, 2015 at 4:12 PM, Dmitry Stogov 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 the
maintainer
> 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 need
On Mon, Feb 2, 2015 at 7:47 PM, Paul Dragoonis wrote:
> 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
On 2 February 2015 at 17:00, François Laupretre 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 the needle
>
> 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 opti
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 wrote:
> When submitting an RFC, please open a separate thread. Otherwise people who
> do not follow every single discussion will not see it.
>
Hi,
On Mon, Feb 2, 2015 at 7:00 PM, François Laupretre 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 the
On Tue, Dec 2, 2014 at 11:28 AM, Ferenc Kovacs wrote:
>
>
> On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins
> 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 whats coming next! ;)
On Mon, Feb 2, 2015 at 7:00 PM, Andrea Faulds wrote:
> Hi Andrey,
>
>> On 2 Feb 2015, at 16:57, Andrey Andreev wrote:
>>
>> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds wrote:
>>> Hi Andrey,
>>>
On 2 Feb 2015, at 16:48, Andrey Andreev wrote:
As already said, we're just going aro
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
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 Andrey,
> On 2 Feb 2015, at 16:57, Andrey Andreev wrote:
>
> On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds wrote:
>> Hi Andrey,
>>
>>> On 2 Feb 2015, at 16:48, Andrey Andreev wrote:
>>>
>>> As already said, we're just going around in circles at this point, but
>>> a migration issue?
>>>
Hi,
On Mon, Feb 2, 2015 at 6:52 PM, Andrea Faulds wrote:
> Hi Andrey,
>
>> On 2 Feb 2015, at 16:48, Andrey Andreev 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
>>
> 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 Andrey,
> On 2 Feb 2015, at 16:48, Andrey Andreev 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 code adds ty
Hi Matthew,
> On 2 Feb 2015, at 16:45, Matthew Leverton wrote:
>
> On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds 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 test
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? Th
Hi,
On Mon, Feb 2, 2015 at 6:39 PM, Andrea Faulds wrote:
> Hey Derick,
>
>> On 2 Feb 2015, at 16:35, Derick Rethans 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.
>>>
>>
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! :)
On Sun, Feb 1, 2015 at 5:49 PM, Andrea Faulds 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:
> htt
> 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
Hey Derick,
> On 2 Feb 2015, at 16:35, Derick Rethans 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 change
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: http://www.php.net/unsub.p
> 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];
>
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 hinti
Hey Nikita,
> On 2 Feb 2015, at 16:32, Nikita Popov wrote:
>
> On Mon, Feb 2, 2015 at 4:27 PM, Andrea Faulds wrote:
> Hey Nikita,
>
> > On 2 Feb 2015, at 13:49, Nikita Popov wrote:
> >
> > I've voted -1 because I think this should be a function and not an
> > operator. compare($a, $b) is mor
On Mon, Feb 2, 2015 at 4:27 PM, Andrea Faulds wrote:
> Hey Nikita,
>
> > On 2 Feb 2015, at 13: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 funct
Hi Dmitry,
> On 2 Feb 2015, at 09:24, Dmitry Stogov 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 enforci
Hi,
On Mon, Feb 2, 2015 at 6:17 PM, Andrea Faulds wrote:
> Hi Markus,
>
>> On 2 Feb 2015, at 14:25, Markus Fischer 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 mov
Hi Markus,
> On 2 Feb 2015, at 14:25, Markus Fischer 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 weak types fo
On Mon, Feb 2, 2015 at 12:03 PM, Leigh 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 just in open
On Mon, Feb 2, 2015 at 2:30 PM, Daniel Lowrey 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. Six pa
On Mon, Feb 2, 2015 at 8:27 AM, Andrea Faulds wrote:
> Hey Nikita,
>
>> On 2 Feb 2015, at 13: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 funct
On 2 February 2015 at 14:30, Daniel Lowrey 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. Six paramet
Hey Nikita,
> On 2 Feb 2015, at 13: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
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
> 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
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:
> https://wiki.php.ne
1 - 100 of 129 matches
Mail list logo
