Am 14.09.2014 um 22:41 schrieb Andrea Faulds:
> Given PHP now has a (admittedly work-in-progress) language specification,
> would it be reasonable to make an RFC to amend the current rules, such
> that RFCs that change the language must include a patch to the
> specification?
+1
--
PHP Internal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 11/09/2014 09:19, Remi Collet a écrit :
> Le 11/09/2014 09:16, Remi Collet a écrit :
>> Le 09/09/2014 07:54, Stas Malyshev a écrit : The big issue I
>> see, is the news entry:
>
>> . Fixed #65641 (PHP-FPM incorrectly defines the SCRIPT_NAME
>> var
Hi!
> The above are, as far as I’m concerned, all potential candidates for
> removal in PHP 7, so in order to reliably test a deprecated function
> I would suggest introducing a hidden function with this signature:
>
> void __deprecated__() { }
>
> And mark that function as eternally deprecated
Hi!
> This is exactly the issue we are battling here. One side wants to be
> consistent with inconsistencies (and tbh quite confusing) while the other
> side wants to allow userland implemented APIs to actually be consistent.
It's not the issue here. Nobody wants 100% of functions to do the same,
On 15 Sep 2014 05:59, "Matt Ficken" wrote:
>
> In making/merging major changes (like concurrency) the most important
thing is to not break that compatibility and dependability:
>
> Your patch will fail without the /proc filesystem(mac osx?). On Windows,
you can check the %NUMBER_OF_PROCESSORS% en
When building PFTT, the PHP Full Test Tool, one goal was maximizing speed
so that we would be more likely to frequently Fully test PHP (Full-coverage
of many scenarios), and to do that I built it to run tests concurrently...
Concurrent/parallel execution can cause breaks that otherwise work with
n
On Sun, Sep 14, 2014 at 8:36 PM, Levi Morrison wrote:
> On Fri, Sep 5, 2014 at 2:29 PM, Levi Morrison wrote:
>> Dear list,
>>
>> I have opened voting on this RFC:
>> https://wiki.php.net/rfc/switch.default.multiple#vote
>>
>> The RFC is very short so I will not summarize it here.
>>
>> Voting wil
On Fri, Sep 5, 2014 at 2:29 PM, Levi Morrison wrote:
> Dear list,
>
> I have opened voting on this RFC:
> https://wiki.php.net/rfc/switch.default.multiple#vote
>
> The RFC is very short so I will not summarize it here.
>
> Voting will remain open for 10 days and will close on Monday,
> September t
On Sun, Sep 14, 2014 at 3:22 PM, Derick Rethans wrote:
> We can either have casting where:
>
> function bar(int $foo) { }
> bar("42");
>
> Means the same as:
>
> function bar($foo) { }
> bar((int) "42");
>
> Or we can have it as a strict cast, or we can have it like
On 14/09/2014 20:01, Pierre Joye wrote:
One side wants to be consistent with inconsistencies (and tbh quite
confusing) while the other side wants to allow userland implemented
APIs to actually be consistent.
I'm not sure that's quite fair. The only thing that would be consistent
with existing
On 14/09/2014 21:22, Derick Rethans wrote:
Or we can have it as a strict cast, or we can have it like it currently
(ie, not at all). I can live with those three options, but not an
option where casting/checking does something different again.
Is there an existing, documented, definition of "str
Good evening,
This RFC has been put to a vote. It starts today (2014-09-14) and ends in a
week’s time (2014-09-21).
https://wiki.php.net/rfc/integer_semantics#vote
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://
Good evening,
Given PHP now has a (admittedly work-in-progress) language specification, would
it be reasonable to make an RFC to amend the current rules, such that RFCs that
change the language must include a patch to the specification?
Thanks!
--
Andrea Faulds
http://ajf.me/
--
PHP Intern
On 14 Sep 2014, at 21:22, Derick Rethans wrote:
> But this "compromise" introduces yet another set of casting rules. And
> that is why will advocate and vote against this.
>
> We can either have casting where:
>
> function bar(int $foo) { }
> bar("42");
>
> Means the same as:
>
On Sun, 14 Sep 2014, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 13:17, Zeev Suraski wrote:
>
> > I honestly don't see why we can't be consistent for the simple
> > types, or at least strive to be as consistent as possible as opposed
> > to introducing a complete parallel universe for userlan
Hello Andrea,
I find the rfc a bit difficult to understand:
e.g. is_float('1') gives false, but foo('1') with function foo(float $a){} is
ok.
Regards,
Thomas
Andrea Faulds wrote on 14.09.2014 01:30:
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
On Sep 14, 2014 8:21 PM, "Rowan Collins" wrote:
> As Andrea points out, one of the big problems in this discussion is that
those internal functions aren't actually consistent with one another - some
of the logic is built into zned_parse_parameters, but fallback behaviour
and additional checks are
On 14/09/2014 17:41, Andrey Andreev wrote:
Perhaps I should explain what an “internal function” is in PHP parlance. An
internal function is one which is exposed to userland, but is implemented in C
via an extension, rather than in PHP. Examples include literally every function
in PHP’s documen
On 14 Sep 2014, at 18:34, Stas Malyshev wrote:
> Hi!
>
>> The “possible changes” section only details possible *changes*, that
>> is, changes to the RFC that could be made, but have not been. So you
>
> OK, so by "possible changes" you mean things that could have been into
> RFC, but were reje
Hi!
> The “possible changes” section only details possible *changes*, that
> is, changes to the RFC that could be made, but have not been. So you
OK, so by "possible changes" you mean things that could have been into
RFC, but were rejected and are not part of the RFC? Then I agree it is
clear but
On 14 Sep 2014, at 18:29, Stas Malyshev wrote:
> Hi!
>
>> The vote would be for the RFC as it is. Possible changes are things
>> in the RFC I was uncertain on. I might hold votes on some of them,
>> actually.
>
> I'm sorry, but this makes little sense to me. There are a number of
> mutually co
Hi!
> The vote would be for the RFC as it is. Possible changes are things
> in the RFC I was uncertain on. I might hold votes on some of them,
> actually.
I'm sorry, but this makes little sense to me. There are a number of
mutually contradictory options here, how you can vote for them "as it
is"?
On 14/09/2014 08:54, Lester Caine wrote:
One has to assume first that what is returned is a simple byte
string array while currently is IS possible that it will contain unicode
characters?
Well, currently, every single string function in PHP treats a string as
a simple byte array, apart from t
On 14 Sep 2014, at 18:23, Dan Ackroyd wrote:
> When you re-open the voting, please can you have an option that is
> 'Yes - without numeric typehint’ ?
I was already planning that, actually. :)
> Although I like the idea of the RFC, having a type-hint that matches
> multiple scalar types seems
Hi Andrea,
When you re-open the voting, please can you have an option that is
'Yes - without numeric typehint' ?
Although I like the idea of the RFC, having a type-hint that matches
multiple scalar types seems distinctly weird to me.
It really needs a separate case making for it, separate from t
On Sun, Sep 14, 2014 at 7:17 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 17:09, Andrey Andreev wrote:
>
>> I'm aware of that, hence why I said 'php-internals' to refer to the
>> mailing list. Again, userland devs don't care about that - PHP is
>> their language and they only care how we/they
On 14 Sep 2014, at 17:09, Andrey Andreev wrote:
> I'm aware of that, hence why I said 'php-internals' to refer to the
> mailing list. Again, userland devs don't care about that - PHP is
> their language and they only care how we/they interact with it, not
> what happens under the hood.
Yes. Int
On Sun, Sep 14, 2014 at 6:47 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 16:40, Andrey Andreev wrote:
>
>> ... and I responded to this in the next paragraph. Userland doesn't
>> case about internal differences, that's why they're called internal
>> and why people outside of php-internals have
On 14 Sep 2014, at 16:40, Andrey Andreev wrote:
> ... and I responded to this in the next paragraph. Userland doesn't
> case about internal differences, that's why they're called internal
> and why people outside of php-internals have for so long been puzzled
> why we only have array and object
Hi,
On Sun, Sep 14, 2014 at 6:09 PM, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
>
>> It seems a bit political ... A lot of people want either strict type
>> hints or type casting hints, but because the people on this list can't
>> get to agree on any of the two, thi
On 14 Sep 2014, at 15:56, Andrey Andreev wrote:
> It seems a bit political ... A lot of people want either strict type
> hints or type casting hints, but because the people on this list can't
> get to agree on any of the two, this RFC tries to make a compromise
> that, IMO, satisfies nobody. It'
Hi,
As a userland guy, I'm against this one.
It seems a bit political ... A lot of people want either strict type
hints or type casting hints, but because the people on this list can't
get to agree on any of the two, this RFC tries to make a compromise
that, IMO, satisfies nobody. It's done not f
On 14 Sep 2014, at 13:17, Zeev Suraski wrote:
> I honestly don't see why we can't be consistent for the simple types, or
> at least strive to be as consistent as possible as opposed to introducing
> a complete parallel universe for userland functions, that's inconsistent
> with the entirety of t
> -Original Message-
> From: Andrea Faulds [mailto:a...@ajf.me]
> Sent: Sunday, September 14, 2014 3:08 PM
> To: Stas Malyshev
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
>
>
> The problem is that we *can't* be consistent. Internal functi
> On 14 Sep 2014, at 07:32, Stas Malyshev wrote:
>
> Calling this "scalar type hinting with cast" when it doesn't actually
> cast in wide variety of cases sounds a bit misleading to me. It should
> be called "scalar type checking with restricted casting" or something
> like that.
I'd agree it's
> From: a...@ajf.me
> Date: Sun, 14 Sep 2014 00:30:40 +0100
> To: internals@lists.php.net
> Subject: [PHP-DEV] [VOTE][RFC] Scalar Type Hinting with Cast
>
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
>
> I would urge you to vote in favour. It is
On Sun, Sep 14, 2014 at 11:12 AM, Alain Williams wrote:
> On Sun, Sep 14, 2014 at 01:10:20AM +0100, Andrea Faulds wrote:
>>
>> On 14 Sep 2014, at 01:07, Alain Williams wrote:
>>
>> > You give an option for float to int casting to truncate.
>>
>> Where?
>
> Possible Changes
>
> Float to In
On Sun, Sep 14, 2014 at 01:10:20AM +0100, Andrea Faulds wrote:
>
> On 14 Sep 2014, at 01:07, Alain Williams wrote:
>
> > You give an option for float to int casting to truncate.
>
> Where?
Possible Changes
Float to Int Casting Rules
...
This could be relaxed for semi-representab
hi Andrea,
On Sun, Sep 14, 2014 at 1:30 AM, Andrea Faulds wrote:
> Good evening,
>
> I’ve given up on my plan B, so I’m putting this RFC, finally, to a vote.
>
> I would urge you to vote in favour. It is not going to please everyone, it is
> after all a compromise proposal. However, I have tried
On 14/09/14 07:48, Stas Malyshev wrote:
>> Please take a look and make your opinion.
>> >
>> > https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>> >
>> > This inconsistency might be interpreted like a bug, but fixing it might
>> > break existing PHP code (at least my attempt to fix it in
40 matches
Mail list logo
