Hi all,
On Sat, Feb 21, 2015 at 10:06 AM, Yasuo Ohgaki wrote:
> I think this will be the final discussion before vote.
> This RFC is to make PHP stronger against script inclusion attacks just
> like other languages.
>
> https://wiki.php.net/rfc/script_only_include
>
> I hope everyone will like t
On 22 בפבר׳ 2015, at 02:07, François Laupretre wrote:
>> De : Lester Caine [mailto:les...@lsces.co.uk]
>>
>> Fixed length fields may well be a data source so having to strip them
>> before using them just seems a backward step. The basic C library simply
>> strips the white space so are we loo
2015-02-21 17:26 GMT-04:00 Pavel Kouřil :
> Hello,
>
> finally got to this, after a while of thinking - the first part was
> answered before, so I'll get only to the str_replace now. :)
>
> Basically, each of the 8 different version based on parameters does
> different thing, if I'm counting it co
On 21 February 2015 at 23:13, Lester Caine wrote:
> On 21/02/15 19:56, Pádraic Brady wrote:
>> 1. Happy to see leading/trailing spaces excluded.
> Fixed length fields may well be a data source so having to strip them
> before using them just seems a backward step. The basic C library simply
> stri
On 22/02/15 00:52, Pierre Joye wrote:
> My gut feeling, having quite a large users base to back my rough
> estimation, is that most won't even know or notice it.
The majority of users have no need for it at all ... so is there any
need for it to be even compiled in for a general user ?
--
Lester
On 22/02/15 00:07, François Laupretre wrote:
>>> 3. "1E07" might be construed as overly generous assuming we are
>>> > > excluding stringy integers like hex, oct and binary
>> > Yet again ... If we have to add a lot of extra checks then why can't we
>> > simply ask if the data is a usable integer.
Hi all,
On Sat, Feb 21, 2015 at 3:28 AM, Adam Harvey wrote:
> On 20 February 2015 at 04:54, Niklas Keller wrote:
> > Question: The timline says "Line up any remaining RFCs that target PHP
> > 7.0.", does that mean RFCs have to
> > start voting on Mar 15 or should the vote end there?
>
> My inte
On Feb 21, 2015 4:29 PM, "François Laupretre" wrote:
>
> > De : Anthony Ferrara [mailto:ircmax...@gmail.com]
> > Saying that turning on an optional and previously unavailable option
inside
> > code causing code breaks is any way a " BC" break is pure FUD.
>
> Who talked of BC break for this ?
>
>
> De : Anthony Ferrara [mailto:ircmax...@gmail.com]
> Saying that turning on an optional and previously unavailable option inside
> code causing code breaks is any way a " BC" break is pure FUD.
Who talked of BC break for this ?
I probably missed something because there's no BC break here, just a
> De : Lester Caine [mailto:les...@lsces.co.uk]
>
> Fixed length fields may well be a data source so having to strip them
> before using them just seems a backward step. The basic C library simply
> strips the white space so are we looking at using an alternative?
I guess you got it wrong : we'll
On Feb 21, 2015 1:54 PM, "Yasuo Ohgaki" wrote:
>
> Hi Pierre,
>
> On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye wrote:
>>
>> > Assertion is only for development and testing.
>> > We need errors or exceptions during development and testing, but
>> > not in production. Therefore, errors/exception sh
Zeev,
> > > Two more things regarding the competing RFC – it’s still alive, and
> > > being promoted for PHP 7.0; And while it doesn’t create a huge BC
> > > break, it allows developers to selectively create localized BC breaks,
> > > on a per file basis.
> >
> > No, it does not. A BC break is so
On Feb 21, 2015 2:02 PM, "Zeev Suraski" wrote:
> > I agree we should have users avoid explicit casts. That's why the
> > dual-mode
> > proposal exists. If users don't want to control their types, they should
> > use the
> > default mode. And everything works fine.
>
> This ignores the reasonable
On 21/02/15 22:12, Yasuo Ohgaki wrote:
>> This driver returns all column data as a string, regardless of how it's
>> > represented in the DB. I created a patch for my own use that syncs up the
>> > type handling with the behavior of the MSSQL extension. This seems like it
>> > would be of general u
Hi,
I intended on replying to this thread at a later stage (and probably
will), but I just can't ignore this one:
On Sun, Feb 22, 2015 at 12:02 AM, Zeev Suraski wrote:
>
> Secondly, there you are: http://www.checkmarx.com/ - they've been
> developing pretty amazing static analyzers for PHP for
On 21/02/15 19:56, Pádraic Brady wrote:
> 1. Happy to see leading/trailing spaces excluded.
Fixed length fields may well be a data source so having to strip them
before using them just seems a backward step. The basic C library simply
strips the white space so are we looking at using an alternative
Hey Dan,
> Making it easier to write bad (imo) code does
> not seem a good reason for a change.
The point of this language feature isn't to promote or simplify the creation of
bad code. Developers can (and will) misuse any feature to write poor code.
The aim of this RFC is to enable developers
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Sunday, February 22, 2015 12:25 AM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> Zeev,
>
>
> "with two potential 'camps' of developers forming up"
>
> Have
On Sat, Feb 21, 2015 at 11:25 PM, Zeev Suraski wrote:
> There’s a fundamental difference between the two RFCs that goes beyond
> whether using a global INI setting and the other per-file setting. The
> fundamental difference is that the endgame of the Dual Mode RFC is having
> two modes – and wha
Benjamin,
There’s a fundamental difference between the two RFCs that goes beyond
whether using a global INI setting and the other per-file setting. The
fundamental difference is that the endgame of the Dual Mode RFC is having
two modes – and whatever syntax we’ll add, will be with us forever;
Zeev,
On Sat, Feb 21, 2015 at 5:02 PM, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Saturday, February 21, 2015 10:08 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>>
>> Zeev
Hi Pierre,
I'm currently writing a patch to test the proposed ruleset, as BC is the key
point.
If BC breaks are so massive that we have to revert to the original 'weak' mode,
I will be the first one to vote for dual-mode.
There will be two slightly different branches : one totally disabling
(
Hi Adam,
On Sat, Feb 21, 2015 at 2:22 AM, Adam Baratz wrote:
> This driver returns all column data as a string, regardless of how it's
> represented in the DB. I created a patch for my own use that syncs up the
> type handling with the behavior of the MSSQL extension. This seems like it
> would
Márcio,
I hope to be able to work on an actual implementation and have something by
the end of the upcoming week, allowing us all to experiment.
Other than tweaking the conversion table, which based on the feedbacks I *
*believe** can be done in a way everyone can live with – I agree that the
b
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Saturday, February 21, 2015 10:08 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> Zeev,
>
> I won't nit-pick every point, but there are a few I think need
Hi Pierre,
On Sun, Feb 22, 2015 at 2:53 AM, Pierre Joye wrote:
> > Assertion is only for development and testing.
> > We need errors or exceptions during development and testing, but
> > not in production. Therefore, errors/exception should not be catched
> > by code in general. Isn't assertion
Hi Zeev,
On Sat, Feb 21, 2015 at 6:22 PM, Zeev Suraski wrote:
> All,
>
>
>
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
>
>
> I think it’s the RFC is a bit premature and could benefit from
On Wed, Feb 18, 2015 at 9:45 PM, Benjamin Eberlei wrote:
>
>
> On Wed, Feb 18, 2015 at 9:29 PM, Pavel Kouřil wrote:
>>
>> As a Doctrine user, I find this way worse than current state. This
>> syntax looks UGLY and contains a lot of useless clutter. And yeah,
>> adding named parameters to PHP be p
On Mon, Feb 16, 2015 at 9:50 PM, François Laupretre wrote:
>> De : Pavel Kouril [mailto:pajou...@gmail.com]
>>
>> Hello,
>>
>> I know this is probably a pretty unpopular opinion in PHP (based on
>> the replies I got in the other thread), but different values for
>> parameters should be IMHO solved
Hi Dan,
On Sun, Feb 22, 2015 at 12:40 AM, Dan Ackroyd
wrote:
> From the RFC:
> > Patches and Tests
> > Will be prepared before vote.
>
> The implementation details may determine how some people vote. Is the
> patch still coming before the voting is opened?
>
Yes. The patch will be simple one.
I
Hi Jan,
On Sun, Feb 22, 2015 at 12:33 AM, Jan Ehrhardt wrote:
> Yasuo Ohgaki in php.internals (Sat, 21 Feb 2015 10:06:24 +0900):
> >I think this will be the final discussion before vote.
> >This RFC is to make PHP stronger against script inclusion attacks just
> like
> >other languages.
> >
> >h
Hi Zeev,
On 21.02.15 18:22, Zeev Suraski wrote:
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
> I think it’s the RFC is a bit premature and could benefit from a bit more
> time, but given th
> -Original Message-
> From: Pádraic Brady [mailto:padraic.br...@gmail.com]
> Sent: Saturday, February 21, 2015 9:56 PM
> To: Zeev Suraski
> Cc: Anthony Ferrara; PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
>
> The sentence stresses garbage in too much to read as
On Feb 20, 2015 11:35 PM, François Laupretre wrote:
>
> Hi Pierre,
>
> > De : Pierre Joye [mailto:pierre@gmail.com]
> >
> > I do think we should. We are exactly at the point I was afraid to
> > reach with the unrealistic planning for 7. Engine is somehow stable
> > from an API changes po
Hi Nikita,
> -Ursprüngliche Nachricht-
> Von: Niktia Nefedov [mailto:inefe...@gmail.com]
> Gesendet: Freitag, 20. Februar 2015 22:43
> An: internals@lists.php.net
> Betreff: [PHP-DEV] Allow to use argument unpacking at any place in
> arguments list
>
> Hey folks,
>
> Currently argument
On Sat, Feb 21, 2015 at 11:11 AM, Zeev Suraski wrote:
> Sorry for the previous prematurely sent email, looks like I found a new
> keyboard shortcut :)
>
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Saturday, February 21, 2015 8:12 PM
>> To: Zeev Sura
Hi,
2015-02-21 14:22 GMT-03:00 Zeev Suraski :
> All,
>
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
> I think it’s the RFC is a bit premature and could benefit from a bit more
> time, but g
Copying from old thread...please ignore the original.
On 21 February 2015 at 18:13, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Saturday, February 21, 2015 8:12 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DE
Zeev,
I won't nit-pick every point, but there are a few I think need to be clarified.
>> > Proponents of Dynamic STH bring up consistency with the rest of the
>> language, including some fundamental type-juggling aspects that have been
>> key tenets of PHP since its inception. Strict STH, in thei
On Fri, Feb 20, 2015 at 10:35 PM, François Laupretre wrote:
> Hi Pierre,
>
>> De : Pierre Joye [mailto:pierre@gmail.com]
>>
>> I do think we should. We are exactly at the point I was afraid to
>> reach with the unrealistic planning for 7. Engine is somehow stable
>> from an API changes point o
On 21 February 2015 at 18:13, Zeev Suraski wrote:
>> -Original Message-
>> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
>> Sent: Saturday, February 21, 2015 8:12 PM
>> To: Zeev Suraski
>> Cc: PHP internals
>> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>>
>> Zeev,
>>
>> Fir
I see a LOT of "no" votes against this RFC but can't find the thread
outlining the reasoning for such resistence.
Could someone link me to this somehow?
On Sat, Feb 21, 2015 at 1:43 PM, Pascal Martin, AFUP <
mail...@pascal-martin.fr> wrote:
> Le 08/02/2015 09:14, Stanislav Malyshev a écrit :
>
>
> De : Anthony Ferrara [mailto:ircmax...@gmail.com]
>
> I've taken a look at that proposal, and here are my comments:
Thanks
> 1. This RFC only talks about ZPP. I assume you're also talking about
> exposing the same ruleset to userland?
Right. This is a sub-RFC of STH main. As it is stated in i
Sorry for the previous prematurely sent email, looks like I found a new
keyboard shortcut :)
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Saturday, February 21, 2015 8:12 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar
On Sat, Feb 21, 2015 at 10:28 AM, Anthony Ferrara wrote:
> Pierre,
>
>> And finally, this RFC only proposes one solution, so competitive RFCs
>> are still required to actually represent alternatives.
>
> That is a good thing. it should only propose one solution. Making a
> single RFC proposing two
Pierre,
> And finally, this RFC only proposes one solution, so competitive RFCs
> are still required to actually represent alternatives.
That is a good thing. it should only propose one solution. Making a
single RFC proposing two solutions would be a MASSIVE mistake IMHO as
these proposals are co
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Saturday, February 21, 2015 8:12 PM
> To: Zeev Suraski
> Cc: PHP internals
> Subject: Re: [PHP-DEV] Coercive Scalar Type Hints RFC
>
> Zeev,
>
> First off, thanks for putting forward a proposal. I look forward
> De : Anthony Ferrara [mailto:ircmax...@gmail.com]
>
> Callable is an existing rule, which is not subject to the "strict" discussion.
I was talking of __invoke() and closures, wich extend callable from
'string|array' to 'string|array|object'. But, I agree, it just extends the rule.
> None of th
Zeev,
First off, thanks for putting forward a proposal. I look forward to a
patch that can be experimented with.
There are a few concerns that I have about the proposal however:
> Proponents of Strict STH cite numerous advantages, primarily around code
> safety/security. In their view, the conv
On Sat, Feb 21, 2015 at 9:51 AM, Zeev Suraski wrote:
> [Resending with the correct Subject line :)]
>
> ---
>
> All,
>
>
>
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
>
>
> I think it’s the
OK, sorry, I was a little negligent with local times. I said that because I
sent another message some hours ago. And I was honest when saying ‘I think you
didn’t have time to reply’ because I knew it was short. No irony here even if I
agree it may seem so, especially in the context.
Actually
On Fri, Feb 20, 2015 at 7:10 PM, Yasuo Ohgaki wrote:
> Hi Crypto,
>
> On Fri, Feb 20, 2015 at 11:02 PM, Crypto Compress <
> cryptocompr...@googlemail.com> wrote:
>
>> AssertionExceptions are not intended to be caught, they are intended to be
>>> seen, in a specific environment.
>>>
>>
>> Joe, your
[Resending with the correct Subject line :)]
---
All,
I’ve been working with François and several other people from internals@
and the PHP community to create a single-mode Scalar Type Hints proposal.
I think it’s the RFC is a bit premature and could benefit from a bit more
time, but given
hi,
On Sat, Feb 21, 2015 at 9:22 AM, Zeev Suraski wrote:
> All,
>
>
>
> I’ve been working with François and several other people from internals@
> and the PHP community to create a single-mode Scalar Type Hints proposal.
>
>
>
> I think it’s the RFC is a bit premature and could benefit from a bit
Hi, Nikita
2015-02-20 9:26 GMT-03:00 Nikita Popov :
>
> I think we all agree that it would be nice to not be so strict about
> reserved keywords in some places. As such this RFC hinges on questions of
> implementation.
>
> The RFC uses a purely lexer-based approach, which is nice in principle,
>
All,
I’ve been working with François and several other people from internals@
and the PHP community to create a single-mode Scalar Type Hints proposal.
I think it’s the RFC is a bit premature and could benefit from a bit more
time, but given the time pressure, as well as the fact that a not f
Dan Ackroyd in php.internals (Fri, 6 Feb 2015 16:16:09 +):
>An incomplete checklist for migrating an extension to PHP7
php_imagick (phpseven branch) once again does not compile, this time
because MAKE_STD_ZVAL has been removed and you added it in
imagickkernel_class.c with this commit:
https:/
On Feb 21, 2015 2:08 AM, "Tony Marston" wrote:
>
> ""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...
>
>>
>> On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
wrote:
>>>
>>>
>>> I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exi
Francois,
> Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
> 'string|array|object', are you sure it's worth the pain implementing and
> supporting a dual-mode mechanism, compared to the ruleset I am intending to
> propose (currently in draft): https://wiki.php.net/r
On Sat, Feb 21, 2015 at 4:55 PM, Anthony Ferrara
wrote:
> Francois,
>
> > I sent you a copy of the messages I sent to Sara, asking for more
> details about what you consider as 'deplorable' in them. I also sent
> another message to get your opinion about the new ruleset I could propose.
> It seem
Francois,
> I sent you a copy of the messages I sent to Sara, asking for more details
> about what you consider as 'deplorable' in them. I also sent another message
> to get your opinion about the new ruleset I could propose. It seems you
> didn't have time to reply. Just hope you don't refuse
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Saturday, February 21, 2015 5:23 PM
> To: Zeev Suraski
> Cc: Larry Garfield; internals@lists.php.net
> Subject: Re: [PHP-DEV] Reviving scalar type hints
>
> I'm fine with that. My interpretation was that the f
>From the RFC:
> Patches and Tests
> Will be prepared before vote.
The implementation details may determine how some people vote. Is the
patch still coming before the voting is opened?
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
On 21 February 2015 at 07:20, Markus Fischer wrote:
> On 21.02.15 06:11, Thomas Punt wrote:
> From the RFC:
>> Also, it will make empty() more inline with the not-too-disimillar isset(),
>
> Here I disagree.
>
> I would have assumed from the start that empty() would only return true
> if *all* of
All,
I have updated the RFC to re-target 7.0.
I have also added a new behavior:
Currently, if you install an error handler that returns true, you can
bypass type checking in userland functions.
set_error_handler(function() { return true; });
function foo(int $abc) {
var_dump($abc);
}
foo("t
Yasuo Ohgaki in php.internals (Sat, 21 Feb 2015 10:06:24 +0900):
>I think this will be the final discussion before vote.
>This RFC is to make PHP stronger against script inclusion attacks just like
>other languages.
>
>https://wiki.php.net/rfc/script_only_include
>
>I hope everyone will like this p
Zeev,
> Anthony,
>
> Following Adam's analysis of the timeline, taking the more 'strict' (no pun
> intended!) interpretation of the timeline RFC, we still have until tomorrow
> to start the discussion and still target it for 7.0, no? Given the
> importance of this topic, I'd go for the more lax i
Francois,
On Fri, Feb 20, 2015 at 8:14 PM, François Laupretre wrote:
> Hi Anthony,
>
> I guess you would keep supporting __toString() ? So, you should probably
> consider 'string' as 'string|object'.
> Adding this case to 'float' meaning 'int|float' and 'callable' resolving to
> 'string|array|o
Hi Anthony,
I sent you a copy of the messages I sent to Sara, asking for more details about
what you consider as 'deplorable' in them. I also sent another message to get
your opinion about the new ruleset I could propose. It seems you didn't have
time to reply. Just hope you don't refuse commun
// Sorry, having email formatting problems still. Hopefully this one will be
more legible.
Hey Markus,
> From the RFC:
> > This behaviour seems to be the most prevalent usage of multiple empty
> checks in a condition, therefore benefitting the most end users.
>
> Here I disagree.
>
> I would hav
Hey Markus,
> From the RFC:
> > This behaviour seems to be the most prevalent usage of multiple empty
> checks in a condition, therefore benefitting the most end users.
>
> Here I disagree.
>
> I would have assumed from the start that empty() would only return true
> if *all* of the ent
Le 08/02/2015 09:14, Stanislav Malyshev a écrit :
I'd like to announce a vote on parameter skipping RFC:
https://wiki.php.net/rfc/skipparams
Hi,
After discussing this RFC with other people at AFUP, we would be -1.
Basically, even though not having to specify the default-value for some
parame
Hi Dennis,
OK, I understand better :)
> De : Dennis Birkholz [mailto:den...@birkholz.biz]
>
> Currently, all traits, classes and interfaces share a common symbol
> table. So if a trait Foo exists in a namespace bar\, not interface or
> class with name Foo can also exist inside that namespace.
>
Hey Leigh,
> Hey Tom,
>
> Patch looks solid (basically the same as the isset logic with OR
> instead of AND). I think it's fairly sane to have this feature because
> it compliments isset functionality (although I dislike "empty"
> personally - consistency is nice)
>
> No RFC would be complete wi
""Nikita Nefedov"" wrote in message news:op.xuco5eutc9evq2@nikita-pc...
On Fri, 20 Feb 2015 12:39:33 +0300, Tony Marston
wrote:
I disagree. Exceptions were originally invented to solve the
semipredicate problem which only exists with procedural functions, not
object methods. Many OO puris
> -Original Message-
> From: Anthony Ferrara [mailto:ircmax...@gmail.com]
> Sent: Saturday, February 21, 2015 1:36 AM
> To: Larry Garfield
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] Reviving scalar type hints
>
> Larry,
>
> On Fri, Feb 20, 2015 at 6:31 PM, Larry Garfield
> wrot
Hi Padraic,
On Sat, Feb 21, 2015 at 5:18 PM, Pádraic Brady
wrote:
> Does this have any impact on allow_url_include or has that setting
> been retained?
>
> Yes, folk do indeed try to do this, for example hitting up Google:
>
> http://www.quora.com/Why-do-include-and-require_once-not-work-with-re
Hi François,
> Please give more precise examples. I'm afraid I don't understand :
I try to clarify.
> If you use \ as prefix for builtin types, how do you distinguish this from
> classes ? Would \resource mean the builtin type or a class name ?
Currently, all traits, classes and interfaces sha
Does this have any impact on allow_url_include or has that setting
been retained?
Yes, folk do indeed try to do this, for example hitting up Google:
http://www.quora.com/Why-do-include-and-require_once-not-work-with-remote-files
Paddy
On 21 February 2015 at 01:06, Yasuo Ohgaki wrote:
> Hi all,
79 matches
Mail list logo
