Hi Dmitry,
On Mon, September 22, 2014 08:43, Dmitry Stogov wrote:
> Hi Anatol,
>
>
> I didn't completely get your ideas, but if tsrm_ls_cache can't be
> exported on Windows directly, can we have a copy of tsrm_ls_cache in each
> DLL/EXE
> and initialize it once?
>
> Thanks. Dmitry.
>
Joe and me wa
On 20/09/2014 01:34, Andrea Faulds wrote:
I’ve put the Null Coalesce Operator RFC to a vote:
https://wiki.php.net/rfc/isset_ternary#vote
It is a 2/3 majority vote and ends in a week’s time on 2014-09-27.
Hi,
We've discussed this RFC with other members of AFUP (French UG), and
we've writte
On 26 September 2014 18:41:02 GMT+01:00, Lars Strojny wrote:
>That is exactly my point: instead of "optimising" the switch/case
>construct which is good enough as if/elseif/else replacement I feel our
>time would be better spent on thinking of polymorphism, guards and
>pattern matching.
That soun
Hi Rowan,
On 26 Sep 2014, at 18:11, Rowan Collins wrote:
[...]
> Without the additional guarantees provided by a purely functional
> environment, that's really just inverting the function header and if
> statement.
>
> Adding an extra case to that still means repeating the operator, so isn't t
Hi!
> I had a discussion with another core dev who told me he did the opposite:
> develop on PHP-5.5, then move the fix/feature up to the new branches (first
> PHP-5.6, then master).
If you talking about developing new features, you can not develop on 5.5
because 5.5 is a stable release that is c
Lars Strojny wrote (on 26/09/2014):
Hi everyone,
On 24 Sep 2014, at 23:17, Rowan Collins wrote:
switch ( $number ) use ( === ) {
[...]
switch ( $age ) use ( < ) {
[...]
switch ( calculate_age($birth_date, $departure_date) as $age_at_departure ) use (
< ) {
[...]
switch ( $product ) use
On Fri, Sep 26, 2014 at 6:20 PM, Derick Rethans wrote:
> On Fri, 26 Sep 2014, Ferenc Kovacs wrote:
>
>> On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine
>> wrote:
>>
>> > The question is in the title :-)
>> >
>> > As far as I know, most projects follow this convention: develop on
>> > the master
2014-09-25 17:27 GMT+02:00 Patrick ALLAERT :
> 2014-09-25 9:42 GMT+02:00 Dmitry Stogov :
>
>> Hi,
>>
>> The vote is opened at
>> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>>
>> Thanks. Dmitry.
>>
>
> Hi,
>
> I'm in favor of disabling for consistency as well, however, I wish a
> warn
On Fri, 26 Sep 2014, Ferenc Kovacs wrote:
> On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine
> wrote:
>
> > The question is in the title :-)
> >
> > As far as I know, most projects follow this convention: develop on
> > the master branch, then backport the fixes/features to older
> > versions
On Thu, 25 Sep 2014, Lars Strojny wrote:
> On 25 Sep 2014, at 17:27, Patrick ALLAERT wrote:
> [...]
> >
> > I'm in favor of disabling for consistency as well, however, I wish a
> > warning would be emitted.
>
> Voted in favour of disabling as well but could easily live with the
> other option
Hi!
IMHO defining the value used for the array key should be provided by the
user, like Lester Caine said. Using a state or location based hash behaves
very unexpectedly and I doubt it would be used very much because of that.
Regarding __toString vs. __hash. It depends on what __toString really
On 26 Sep 2014, at 14:25, Pierre Joye wrote:
> On Fri, Sep 26, 2014 at 2:30 PM, Dmitry Stogov wrote:
>> When I started this RFC I didn't thought about objects.
>> Actually, they are handled with the same inconsistency problem.
>>
>> Nikita, feel free to add this note to RFC.
>> May be it'll ch
On Fri, Sep 26, 2014 at 2:30 PM, Dmitry Stogov wrote:
> When I started this RFC I didn't thought about objects.
> Actually, they are handled with the same inconsistency problem.
>
> Nikita, feel free to add this note to RFC.
> May be it'll change mind of some voters :)
>
> also add a link to your
On 26 Sep 2014, at 14:11, Dmitry Stogov wrote:
> just change your vote.
> I just did it. :)
>
> Even if ArrayAccess worked not by design, it's going to be a big
> compatibility issue, removing it.
> Strings support would work for free.
What should I vote then? I want to vote against string s
just change your vote.
I just did it. :)
Even if ArrayAccess worked not by design, it's going to be a big
compatibility issue, removing it.
Strings support would work for free.
Thanks. Dmitry,
On Fri, Sep 26, 2014 at 5:03 PM, Andrea Faulds wrote:
>
> On 26 Sep 2014, at 11:11, Nikita Popov w
On 26 Sep 2014, at 11:11, Nikita Popov wrote:
> So, just to clarify: If we vote to "remove string handling in all cases"
> does that also mean that we "remove ArrayAccess support in all cases"? If
> so, could the RFC please explicitly mention that?
I myself would be in favour of removing string
On 26 Sep 2014, at 11:48, Andrea Faulds wrote:
> On 26 Sep 2014, at 11:46, marius adrian popa wrote:
>
>> Maybe we need an official stance about shellshock
>
> Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m not
> sure there’s much we can reasonably do about it. Simi
When I started this RFC I didn't thought about objects.
Actually, they are handled with the same inconsistency problem.
Nikita, feel free to add this note to RFC.
May be it'll change mind of some voters :)
also add a link to your patch.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 2:11 PM, Nikita Po
looks like Perl magic :(
-1
Dmitry.
On Mon, Sep 22, 2014 at 3:31 PM, Derick Rethans wrote:
> On Sat, 20 Sep 2014, Patrick Schaaf wrote:
>
> > Am 20.09.2014 01:35 schrieb "Andrea Faulds" :
> > >
> > > https://wiki.php.net/rfc/isset_ternary#vote
> >
> > Hi,
> >
> > got a question after being b
I see, thanks for the answer!
On Fri, Sep 26, 2014 at 1:43 PM, Ferenc Kovacs wrote:
>
>
> On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine
> wrote:
>
>> Hi internals,
>>
>> The question is in the title :-)
>>
>> As far as I know, most projects follow this convention: develop on the
>> master b
On Fri, Sep 26, 2014 at 1:29 PM, Florian Margaine
wrote:
> Hi internals,
>
> The question is in the title :-)
>
> As far as I know, most projects follow this convention: develop on the
> master branch, then backport the fixes/features to older versions.
>
> I had a discussion with another core de
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 26/09/2014 13:29, Florian Margaine a écrit :
> Hi internals,
>
> The question is in the title :-)
>
> As far as I know, most projects follow this convention: develop on
> the master branch, then backport the fixes/features to older
> versions.
>
On 26 September 2014 13:37, Ferenc Kovacs wrote:
>
>
> On Fri, Sep 26, 2014 at 12:59 PM, Peter Lind
> wrote:
>
>> On 26 September 2014 12:48, Andrea Faulds wrote:
>>
>> >
>> > On 26 Sep 2014, at 11:46, marius adrian popa wrote:
>> >
>> > > Maybe we need an official stance about shellshock
>> >
On Fri, Sep 26, 2014 at 12:59 PM, Peter Lind wrote:
> On 26 September 2014 12:48, Andrea Faulds wrote:
>
> >
> > On 26 Sep 2014, at 11:46, marius adrian popa wrote:
> >
> > > Maybe we need an official stance about shellshock
> >
> > Do we? As I understand it, this isn’t a PHP-level vulnerabilit
Hi internals,
The question is in the title :-)
As far as I know, most projects follow this convention: develop on the
master branch, then backport the fixes/features to older versions.
I had a discussion with another core dev who told me he did the opposite:
develop on PHP-5.5, then move the fix
On 26 September 2014 12:48, Andrea Faulds wrote:
>
> On 26 Sep 2014, at 11:46, marius adrian popa wrote:
>
> > Maybe we need an official stance about shellshock
>
> Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m
> not sure there’s much we can reasonably do about it. Sim
On 26 Sep 2014, at 11:46, marius adrian popa wrote:
> Maybe we need an official stance about shellshock
Do we? As I understand it, this isn’t a PHP-level vulnerability, and I’m not
sure there’s much we can reasonably do about it. Similarly to the Heartbleed
bug, control is not in our hands he
Maybe we need an official stance about shellshock
I mainly use php-fpm and mod_php (I didn't used php under cgi for years)
http://jaxbot.me/articles/cases-where-bash-shellshock-is-safe-09-25-2014
http://www.reddit.com/r/programming/comments/2hc1w3/cve20146271_remote_code_execution_through_bash/c
On Thu, Sep 25, 2014 at 11:47 PM, Dmitry Stogov wrote:
> It was on design. list() was intended to support plain arrays only.
>
> Thanks. Dmitry.
>
So, just to clarify: If we vote to "remove string handling in all cases"
does that also mean that we "remove ArrayAccess support in all cases"? If
so
On 26/09/14 08:36, Stas Malyshev wrote:
>> I think it makes more sense than a new method on all objects. You could
> Nobody talks about "new method on all objects" (it's also not really
> possible in PHP). We're talking about new magic method, which allows the
> developer to control how class is tr
It's an inconsistent undocumented behavior, that started to work not by
design, but because of implementation issues.
NULL
NULL
By the way, I'm agree, keeping string support might be better for
compatibility.
Thanks. Dmitry.
On Fri, Sep 26, 2014 at 11:16 AM, Stas Malyshev
wrote:
> Hi!
>
> >
Hi!
> and weird to me, and can be quickly emulated with list($a,$b) =
> str_split([“ab”][0]); if someone was actually using it.
BC breaks don't work this way. When somebody's code would break on PHP
7, their first move would not be "oh, great, let's refactor it, it was
too arcane anyway". It woul
Hi everyone,
On 24 Sep 2014, at 23:17, Rowan Collins wrote:
> switch ( $number ) use ( === ) {
[...]
> switch ( $age ) use ( < ) {
[...]
> switch ( calculate_age($birth_date, $departure_date) as $age_at_departure )
> use ( < ) {
[...]
> switch ( $product ) use ( instanceOf ) {
All of these exa
On Sep 25, 2014, at 2:42, Dmitry Stogov wrote:
> Hi,
>
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> Thanks. Dmitry.
Voting for always disabling string handling. This behavior is arcane and weird
to me, and can be quickly emulated with list($a,$b) = st
On Sep 25, 2014, at 2:42, Dmitry Stogov wrote:
> Hi,
>
> The vote is opened at
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> Thanks. Dmitry.
Voting for always disabling string handling. This behavior is arcane and weird
to me, and can be quickly emulated with list($a,$b) = st
Hi!
> In released 5.4.33 (and 5.5.17) you have 6569db8 + 84a4041 + 32be79d
> (notice I have revert these 3 patches for downstream)
>
> In 5.4/5.5/5.6 you have 6569db8 + 84a4041 + 32be79d + f86b219 + 3728449
> (all reverted in 5.6.1)
>
> As you said, "5.4 is now supposed to be security-only
Voting is now open for this RFC. Voting closes around this time on the
3rd of October 2014.
https://wiki.php.net/rfc/pack_unpack_64bit_formats
Thanks,
Leigh.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi!
> Joe Watkins wrote (for fun) a new operator, `addressof`. Code is
> here: https://github.com/krakjoe/php-src/compare/addressof
>
> I think it makes more sense than a new method on all objects. You could
Nobody talks about "new method on all objects" (it's also not really
possible in PHP). W
On 26/09/14 08:08, Leigh wrote:
> My points are:
>
> * Strings are _not_ treated as arrays of bytes everywhere.
> * If we intend to give strings more array-like support after this RFC
> (like foreach($string as $char), making array_* work with strings),
> then I support the list() change.
> * Othe
Hi!
> * Strings are _not_ treated as arrays of bytes everywhere.
This is true. However, sometimes they are. E.g., $string[0] is
meaningful, while array_flip($string) is not.
> * If we intend to give strings more array-like support after this RFC
We don't intend to give strings anything - both $
On 26 September 2014 08:01, Stas Malyshev wrote:
>
> It's as odd as [] working with strings but -> not. Those are different
> things, so they work differently.
Sorry, this was kind of my point, I probably just phrased it badly.
The array_* "question" was meant to be rhetorical.
My points are:
*
Hi!
> Long story short, because FETCH_DIM_R now supports CONST and TMP_VAR
> operands, we can always use it and FETCH_DIM_TMP_VAR can be dropped -
> that's all that has to be done in order to always support strings and
> objects in list(). (I've linked a patch for this previously, see
> https://gi
Hi!
> Why do array_* functions not treat strings as arrays of bytes?
How that's related? We're not talking about array_* functions, we're
talking about list() operator.
> get busy :) - If we want to say "yea list() should work with strings",
> but no other array functions should work with string
43 matches
Mail list logo
