> On 25 May 2016, at 16:56, Dmitry Stogov wrote:
>
> - unset() of typed properties should not be allowed
Potentially opening a larger can of worms: what is the use case of unsetting
any declared property?
Changing this would of course be a huge BC break but it seems less weird then
having di
> On 28 Jan 2016, at 11:02, Rouven Weßling wrote:
>
> voting has started on "Deprecate mb_ereg_replace eval option"
> (https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option)
>
> Voting will end on February 4th.
The RFC has been accepted 19 to 0. Thank yo
Hi internals,
voting has started on "Deprecate mb_ereg_replace eval option"
(https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option)
Voting will end on February 4th.
Best regards
Rouven
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/uns
> On 04 Jan 2016, at 17:46, Rouven Weßling wrote:
>
> I’d like to propose the following RFC to you
> https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option
There hasn’t been any discussion on this for a while. Just to to be sure it
didn’t just got forgotten due to the Co
> On 13 Jan 2016, at 16:15, Ryan Pallas wrote:
>
>> On Wed, Jan 13, 2016 at 7:55 AM, Rouven Weßling
>> wrote:
>>
>> TL;DR: If you find yourself replying more than once an hour to a thread,
>> something is wrong.
>
> Yup, this is explicitly part of
> On 13 Jan 2016, at 16:23, Ferenc Kovacs wrote:
>
> I don't think we can avoid some confusion, we could have had a three way
> vote here (keep the current, expand #1, expand #2) but then people would
> argue that the tho expand options should win in sum or one of those
> separately. We could ha
> On 13 Jan 2016, at 14:57, Zeev Suraski wrote:
>
> I don't see it that way. I think I provided very relevant feedback - that
> yes, called for a very substantial revision of the proposal and a removal of
> a substantial part of it - but I still marked the concept of having a CoC as
> a good
> On 05 Jan 2016, at 21:52, Andrea Faulds wrote:
>
> This is more of a side-note, but maybe it's worth bringing up. Since
> token_get_all gives an array with subarrays of a regular structure, might it
> be worthwhile returning an array of objects instead? It would probably reduce
> memory usa
> On 11 Jan 2016, at 13:27, Pierre Joye wrote:
>
> Hi,
> On Jan 11, 2016 4:12 PM, "Rouven Weßling" wrote:
> >
> > * Is there already a crypt scheme for Argon2? Or are there any efforts to
> > define one? It would good if PHP wouldn’t be an island.
> On 11 Jan 2016, at 07:57, Scott Arciszewski wrote:
>
> Does adding Argon2 as a possible choice for password_hash() +
> password_verify() need an RFC? Or can I just submit a pull request?
The original RFC (https://wiki.php.net/rfc/password_hash) contained the
following text:
> I'd propose th
Hi Scott,
questions inline.
> On 07 Jan 2016, at 14:26, Scott Arciszewski wrote:
>
> I've updated the RFC to make libsodium a core PHP extension in 7.1, to
> include references to the online documentation.
>
> https://wiki.php.net/rfc/libsodium
I know this is made difficult by the fact that t
> On 06 Jan 2016, at 18:03, Dan Ackroyd wrote:
>
> This is possibly a stupid question, but one that needs to be asked anyway:
Certainly not a stupid question.
> Have you checked that simply converting code that uses
> mb_eregi_replace to using mb_ereg_replace_callback with the i flag
> behaves
Hi Dan,
> On 04 Jan 2016, at 20:52, Dan Ackroyd wrote:
>
> Are the wrong functions are listed in this sentence: "Emit an
> E_DEPRECATED error whenever mb_ereg_replace_callback or
> mb_eregi_replace_callback is called with the e option." As the RFC is
> meant to be about mb_ereg_replace, mb_eregi
Dear internals,
I’d like to propose the following RFC to you
https://wiki.php.net/rfc/deprecate_mb_ereg_replace_eval_option
The mandatory discussion period will end January 19th.
Best regards
Rouven
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.ne
On 31 Aug 2014, at 20:34, Chris Wright wrote:
> I have on occasion come across code that uses split(), more often than not
> as if it were explode() with a literal delimiter.
>
> If ereg is to be removed (for which I am +1) does anyone have any
> objections to making split() into an alias of ex
> Am 24.08.2014 um 14:30 schrieb Pierre Joye :
>
> zend_uint > int32_t
Is that a typo? If it's not, why are you changing it to signed?
Best regards
Rouven
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13 Jul 2014, at 17:05, Andrea Faulds wrote:
> On 13 Jul 2014, at 16:00, Rouven Weßling wrote:
>
>> One thing however seems like a rather bad idea, and that is exposing the
>> type of resource in this way. Resources are not compatible between each
>> other, mak
First of all thanks for this proposal. In general I’m hugely in favour of this
approach.
One thing however seems like a rather bad idea, and that is exposing the type
of resource in this way. Resources are not compatible between each other,
making such a hint not very useable. If people start a
Hi Internals!
First let me introduce myself, my name is Rouven Weßling, I'm a student at RWTH
Aachen University and I'm one of the maintainers of the Joomla! Framework (née
Platform). I've been following the internals list for a few months and started
brushing of my C skil
19 matches
Mail list logo
