> On 2 Feb 2015, at 06:43, Xinchen Hui wrote:
> furthermore, I'd like to discuss remove the handle in zend_resource struct..
>
> it may breaks some usage (use resource as long/double/string
I've seen uses in the wild where file handles are used as array keys (yes, I
know, ugly and wrong).
If
> > De : Xinchen Hui [mailto:larue...@php.net]
> > we used to use lval of zval as a handle to access resource type..
> >
> > but now, we introduced a new type IS_RESOURCE, which make the
> > handle(id) sort of redundant .
> >
>
>
> Wrong. The IS_RESOURCE type has nothing to do with PHP 7. O
Hey Sara:
On Mon, Feb 2, 2015 at 4:01 PM, Sara Golemon wrote:
>
>
>> On 2 Feb 2015, at 06:43, Xinchen Hui wrote:
>> furthermore, I'd like to discuss remove the handle in zend_resource struct..
>>
>> it may breaks some usage (use resource as long/double/string
>
> I've seen uses in the wild where
Hi Dmitry,
--
Andrea Faulds
http://ajf.me/
> On 2 Feb 2015, at 07:02, 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 beha
Hi Dmitry,
> On 2 Feb 2015, at 07:02, Dmitry Stogov wrote:
>
> As I already told, in my opinion, version 0.1 was the perfect solution that
> fit into PHP semantic very well.
I don't like the original. Weak types work to a degree, but they don't fulfill
the use case of a lot of developers, and
> On 02 02 2015, at 07:51, François Laupretre wrote:
> Sorry to say that, but are you sure you understand the difference between
> zval types and resource types ?
>
Thanks, you made my day.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
> On 02 02 2015, at 09:01, Sara Golemon wrote:
>
>
>
>> On 2 Feb 2015, at 06:43, Xinchen Hui wrote:
>> furthermore, I'd like to discuss remove the handle in zend_resource struct..
>>
>> it may breaks some usage (use resource as long/double/string
>
> I've seen uses in the wild where file ha
> On 02 02 2015, at 00:49, 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:
> ht
Hi Xinchen,
On Sat, Jan 31, 2015 at 7:15 PM, Xinchen Hui wrote:
> must be fixed,
>
> https://github.com/php/php-src/commit/1a60175e2595a24ebc3b6d80a112d574c6c98f58
>
Impressive work!
It's irrelevant probably. I only get one valgrind leak with TS build now.
NTS is fine.
[yohgaki@dev php-src]$
On 02/02/2015 09:49, Michael Wallner wrote:
On 02 02 2015, at 00:49, 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
Hi,
On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds wrote:
> Hi Dmitry,
>
>> On 2 Feb 2015, at 07:02, Dmitry Stogov wrote:
>>
>> As I already told, in my opinion, version 0.1 was the perfect solution that
>> fit into PHP semantic very well.
>
> I don't like the original. Weak types work to a degr
On 02/02/15 08:53, Matteo Beccati wrote:
>> I think v0.1 had pretty good chances to get accepted, but I’m not so
>> sure about anything that followed.
>> I’m definitely -1 on declare(strict).
>
> I agree. I understand that someone might prefer strict typing, but
> declare() seems so different from
Hi Andrey,
> On 2 Feb 2015, at 08:55, Andrey Andreev wrote:
>
> Hi,
>
>> On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds wrote:
>> Hi Dmitry,
>>
>>> On 2 Feb 2015, at 07:02, Dmitry Stogov wrote:
>>>
>>> As I already told, in my opinion, version 0.1 was the perfect solution that
>>> fit into
what about giving several voting options? yes/no for scalar type hints and
yes/no for declare-strict
Regards
Thomas
Michael Wallner schrieb am 2. Feb 2015 09:49:
>
>> On 02 02 2015, at 00:49, Andrea Faulds wrote:
>>
>> Good evening,
>>
>> The RFC has been updated to cover return types, sinc
Hi Andrea,
On Mon, Feb 2, 2015 at 11:05 AM, Andrea Faulds wrote:
>
> Hi Andrey,
>
>> On 2 Feb 2015, at 08:55, Andrey Andreev wrote:
>>
>> Hi,
>>
>>> On Mon, Feb 2, 2015 at 10:41 AM, Andrea Faulds wrote:
>>> Hi Dmitry,
>>>
On 2 Feb 2015, at 07:02, Dmitry Stogov wrote:
As I alread
hi,
could you please write down few use cases, when strict scalar type hints
are really useful.
Thanks. Dmitry.
On 02/02/15 07:31, Alexander Lisachenko wrote:
> Agree in that point with you, this can be a good instrument if implemented
> in PHP. I see a good point in it by using this with interfaces and "const"
> modifier for parameters:
>
> class Foo {
> public function bar(const Baz $object); // Requi
On Mon, Feb 2, 2015 at 11:41 AM, Andrea Faulds wrote:
> Hi Dmitry,
>
> > On 2 Feb 2015, at 07:02, Dmitry Stogov wrote:
> >
> > As I already told, in my opinion, version 0.1 was the perfect solution
> that
> > fit into PHP semantic very well.
>
> I don't like the original. Weak types work to a de
what is your handle?
On Mon, Feb 2, 2015 at 12:23 AM, Jakub Zelenka 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 things (
found and added, php-src :)
Thanks for your work!
On Mon, Feb 2, 2015 at 4:32 PM, Pierre Joye wrote:
> what is your handle?
>
> On Mon, Feb 2, 2015 at 12:23 AM, Jakub Zelenka wrote:
>> Hello,
>>
>> I'd like to request src karma to merge recently accepted jsond to master
>> and further maintain
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 an
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 wrote:
> Hey:
>
> we used to u
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 it
On 1 February 2015 at 17:57, Jakub Zelenka 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.
> https://github.com/bukka/php-crypto/blob/master/tests/stream_filters_cipher_gcm_dec_read.phpt
> )
On 2 February 2015 at 10:57, Leigh 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 Mon, Feb 2, 2015 at 3:58 AM, Leigh wrote:
> On 2 February 2015 at 10:57, Leigh 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:
Section 3: The scheme
> The
On 2 February 2015 at 11:46, Jason Gerfen 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 reasonable. Tags of 32
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 lang
On Mon, Feb 2, 2015 at 1:06 PM, Andrea Faulds 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) and en
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
> 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 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
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 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
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 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 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
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
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 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
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
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, 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
> 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];
>
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
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
> 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
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
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 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.
>>>
>>
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 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
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
> 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 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
>>
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,
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
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
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 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! ;)
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
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.
>
> 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
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
>
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
> 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
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
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 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
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!
> 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
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,
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 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
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
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 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 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
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 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
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
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
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,
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
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
> -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,
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
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
> -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
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 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
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
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
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 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
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
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('
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
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 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
1 - 100 of 129 matches
Mail list logo
