Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Nov 7, 2014 at 12:47 AM, Will Fitch wrote: > > On Nov 7, 2014, at 12:38 AM, Sherif Ramadan > wrote: > > > > On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch wrote: > >> >> Sherif - I’m just going to be straight here. I haven’t seen support for >> your proposal at all in this thread. You con

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 7, 2014, at 12:38 AM, Sherif Ramadan wrote: > > > > On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch > wrote: > > Sherif - I’m just going to be straight here. I haven’t seen support for your > proposal at all in this thread. You continue to try and make this c

Re: [PHP-DEV] New Standardized HTTP Interface

On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch wrote: > > Sherif - I’m just going to be straight here. I haven’t seen support for > your proposal at all in this thread. You continue to try and make this > case, but it continues to be shot down with absolutely valid issues, and > your only responsiv

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 7, 2014, at 12:16 AM, Sherif Ramadan wrote: > > On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds > wrote: > >> >>> On 7 Nov 2014, at 00:53, Stas Malyshev wrote: >>> >>> Hi! >>> Again, I think you're oversimplifying the problem. For one, you don't >> know

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds wrote: > > > On 7 Nov 2014, at 00:53, Stas Malyshev wrote: > > > > Hi! > > > >> Again, I think you're oversimplifying the problem. For one, you don't > know > >> that the payload is JSON unless you check the Content-type header > yourself, > >> and y

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 7:53 PM, Stas Malyshev wrote: > Hi! > > > Again, I think you're oversimplifying the problem. For one, you don't > know > > that the payload is JSON unless you check the Content-type header > yourself, > > and you really shouldn't have to since PHP could easily do this for y

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

Lester Caine wrote: > On 06/11/14 11:16, Christoph Becker wrote: >>> Yes it is only a number, but a lot more problematic changes WERE pushed through across those three versions which would have been much safer handled by removing e_strict from PHP5.4 rather than trying to live with

[PHP-DEV] [RFC][Vote Cancellation] Return Types

Dear Internals, A bug was discovered in the implementation of the return types RFC[1] that cannot be fixed by the current implementation. A strategy for fixing the bug has been identified but alters some noticeable behavior in PHP-land. I do not want people to feel like I did a bait-and-switch mov

Re: [PHP-DEV] New Standardized HTTP Interface

> On 7 Nov 2014, at 00:53, Stas Malyshev wrote: > > Hi! > >> Again, I think you're oversimplifying the problem. For one, you don't know >> that the payload is JSON unless you check the Content-type header yourself, >> and you really shouldn't have to since PHP could easily do this for you. > >

Re: [PHP-DEV] New Standardized HTTP Interface

Hi! > Again, I think you're oversimplifying the problem. For one, you don't know > that the payload is JSON unless you check the Content-type header yourself, > and you really shouldn't have to since PHP could easily do this for you. Sure, PHP could easily do this, or any other one specific use c

[PHP-DEV] PDO mysql - add feature to enforce single statements?

Problem: With PDO the mysql driver emulated allows multiple queries, where non-emulated does not. This makes SQL injections with PDO mysql potentially much more damaging. Suggested solution: add a PDO attribute that could be set on a connection or a driver option for PDO::prepare to enforce the

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

Hi! > - major BC break: major versions only. 5 major BC breaks allowed per major > version. I'm not sure how such numbers make sense. Why 5 and not 3 or 7 or 17? If that breaks your code, even one is too much. If your code is not affected, why would you care if it's 5 or 15 or 150? I'm afraid thi

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

Hi! > This is exactly what I'm doing right now, requiring the expression to > always be enclosed in parenthesis. I think it's way better to be able to > do this instead of creating temporary variables just to assign a class Why? What's so bad in variables? It doesn't cost that much and makes you

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

Hi! > Also one thing not mentioned in the initial letter - this will also allow > you to use expressions for new operator in the same way: `new > (str_replace('/', '\\', $classPath))()` - just an example. OK, if we apply it consistently - i.e. say anywhere that we allow literal or ${variable-

[PHP-DEV] Re: New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 6:42 AM, Sanford Whiteman wrote: > Prove I "believe a multipart/form-data mime cannot be sent along with a > PUT request" using messages I have sent to this list. You are basically > lying for effect at this point. I never said that, took pains to explain > that I am not s

Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL

> FWIW, there *is* a practical in-use (de facto if nothing else) convention of > using _ in hosts for DKIM: _domainkey is actually in all the DKIM RFCs and in the formal STD 76, see § 3.6.2.1. Namespace, so it's more than a convention! -- PHP Internals - PHP Runtime Development Mailing List To u

Re: [PHP-DEV] [RFC][Vote] Return Types

It fails because class C is not known at the point when we check if A::foo() is compatible with B::foo(). The relation between C and B doesn't really matter in this case (I may provide another example with relation that must be supported). Thanks. Dmitry. On Thu, Nov 6, 2014 at 6:15 PM, Andrea Fa

Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL

> On Thu, Nov 6, 2014 at 3:39 PM, Kévin Dunglas wrote: >> FILTER_VALIDATE_DOMAIN checks conformance with DNS RFCs : total length, >> label length and allowed characters (_ are allowed in domain names but many >> other characters are forbidden such as ~/+...). I'll add IDN support too >> when IDN s

Re: [PHP-DEV] [RFC][Vote] Return Types

> On 6 Nov 2014, at 15:08, Dmitry Stogov wrote: > > Use A or B for return type in B::foo(). It'll lead to compile error anyway > (Class C is not defined). > It's not possible to compile this by design. Ok, let’s try this: I don’t think this can’t be compiled. When you get to B, you know tha

Re: [PHP-DEV] [RFC][Vote] Return Types

Use A or B for return type in B::foo(). It'll lead to compile error anyway (Class C is not defined). It's not possible to compile this by design. Thanks. Dmitry. On Thu, Nov 6, 2014 at 6:00 PM, Andrea Faulds wrote: > > > On 6 Nov 2014, at 07:43, Dmitry Stogov wrote: > > > > It may be a serious

Re: [PHP-DEV] [RFC][Vote] Return Types

> On 6 Nov 2014, at 07:43, Dmitry Stogov wrote: > > It may be a serious new problem. For example you won't be able to compile > the following code at all? > > class A { > function foo(): C {} > } > class B extends A { > function foo(): C {} > } > class C extends B { > function foo(): C {} >

Re: [PHP-DEV] [RFC][Vote] Return Types

On Thu, Nov 6, 2014 at 12:43 AM, Dmitry Stogov wrote: > It's clear, that covariant types are more smart, but not supporting them, > won't prevent access to more specific type properties and methods. > We are not C++ or Java, and we don't need to cast objects to more specific > types. > > On the ot

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

On Thu, Nov 6, 2014 at 2:32 PM, Christoph Becker wrote: > Ferenc Kovacs wrote: > > > On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker > wrote: > > > >> Lester Caine wrote: > >> > >>> Yes it is only a number, but a lot more problematic changes WERE pushed > >>> through across those three version

Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL

Hi, On Thu, Nov 6, 2014 at 3:39 PM, Kévin Dunglas wrote: > FILTER_VALIDATE_DOMAIN checks conformance with DNS RFCs : total length, > label length and allowed characters (_ are allowed in domain names but many > other characters are forbidden such as ~/+...). I'll add IDN support too > when IDN su

Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL

FILTER_VALIDATE_DOMAIN checks conformance with DNS RFCs : total length, label length and allowed characters (_ are allowed in domain names but many other characters are forbidden such as ~/+...). I'll add IDN support too when IDN support for streams will be merged. FILTER_VALIDATE_URL checks confo

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

Ferenc Kovacs wrote: > On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker wrote: > >> Lester Caine wrote: >> >>> Yes it is only a number, but a lot more problematic changes WERE pushed >>> through across those three versions which would have been much safer >>> handled by removing e_strict from P

Re: [PHP-DEV] Better RFC conformance for FILTER_VALIDATE_URL

Hi, On Thu, Nov 6, 2014 at 8:19 AM, Kévin Dunglas wrote: > Hi Andrey, > > Sorry but I think you're wrong. Domain != hostname. Underscore are allowed > in domains (RFC 2181) but not in hostnames (RFC 1123 and next). To quote > Wikipedia: > > "While a hostname may not contain other characters, such

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

On 06/11/14 11:16, Christoph Becker wrote: >> Yes it is only a number, but a lot more problematic changes WERE pushed >> > through across those three versions which would have been much safer >> > handled by removing e_strict from PHP5.4 rather than trying to live with >> > both versions of PHP. >

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

On Thu, Nov 6, 2014 at 12:16 PM, Christoph Becker wrote: > Lester Caine wrote: > > > Yes it is only a number, but a lot more problematic changes WERE pushed > > through across those three versions which would have been much safer > > handled by removing e_strict from PHP5.4 rather than trying to

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

On Thu, Nov 6, 2014 at 3:49 PM, Andrea Faulds wrote: > By merging the symbol tables, you could reference classes like constants > (perhaps it’d return some sort of ReflectionClass-like thing?): > > $x = SomeClass; > $foo = new $x; > > Currently, because SomeClass above would resolve to a

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

> On 6 Nov 2014, at 11:43, Daniel Ribeiro wrote: > > On Thu, Nov 6, 2014 at 3:36 PM, Andrea Faulds wrote: > >> Perhaps, dare I say it, we should merge the constant and class namespaces >> in PHP7? Those are perhaps the least likely to conflict. It’d mean we could >> handle instanceof expressio

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

On Thu, Nov 6, 2014 at 3:36 PM, Andrea Faulds wrote: > Perhaps, dare I say it, we should merge the constant and class namespaces > in PHP7? Those are perhaps the least likely to conflict. It’d mean we could > handle instanceof expressions, and we wouldn’t need to use ::class. Hi Andrea! I'm no

Re: [PHP-DEV] New Standardized HTTP Interface

Prove I "believe a multipart/form-data mime cannot be sent along with a PUT request" using messages I have sent to this list.  You are basically lying for effect at this point. I never said that, took pains to explain that I am not saying that, gave examples utterly to the contrary... yet you ma

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

> On 6 Nov 2014, at 09:29, Daniel Ribeiro wrote: > > On Thu, Nov 6, 2014 at 1:01 PM, Stas Malyshev > wrote: > >> You could of course require the expression to always be enclosed in (), >> but that produces weird syntax where some forms of instanceof work >> without () and some only with (). Gi

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 4:56 AM, Sanford Whiteman wrote: > > PUT is not intended to necessarily store the request entity body on the > file > > system. Its intention is to store the entity body at the request URI. > > I never said it was. I used the expression "store at the URI" about > 10 ten ti

Re: [PHP-DEV] Thresholds of backwards compatibility breaks

Lester Caine wrote: > Yes it is only a number, but a lot more problematic changes WERE pushed > through across those three versions which would have been much safer > handled by removing e_strict from PHP5.4 rather than trying to live with > both versions of PHP. I don't see a problem with regard

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 4:32 AM, Sanford Whiteman wrote: > > > > First of all, RFC 1867 is not a standard. It's an experimental protocol > > definition. > > Oh nonsense. You know very well that RFC 1867 conformance is an > industry standard for file uploading When 2388 says "originally set > out

Re: [PHP-DEV] New Standardized HTTP Interface

> PUT is not intended to necessarily store the request entity body on the file > system. Its intention is to store the entity body at the request URI. I never said it was. I used the expression "store at the URI" about 10 ten times on this topic. You are arguing in bad faith by putting words in

Re: [PHP-DEV] New Standardized HTTP Interface

> Specifically, parsing the form data and populating it somewhere accessible > to the user as it is today in $_POST and making any binary upload available > in $_FILES or some other fashion. Ideally, making handling PUT more > consistent with the way PHP handles POST. OK, the first definition: "ha

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

On Thu, Nov 6, 2014 at 1:01 PM, Stas Malyshev wrote: > You could of course require the expression to always be enclosed in (), > but that produces weird syntax where some forms of instanceof work > without () and some only with (). Given that you can easily assign your > value to a variable, is i

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

On Thu, 06 Nov 2014 13:01:52 +0400, Stas Malyshev wrote: Hi! What I want to implement is the ability to allow arbitrary expressions on the second operand, so instead of having to write something like this: I'm afraid there's a problem with this. Arbitrary expressions include constants,

Re: [PHP-DEV] Allow arbitrary expressions when using instanceof operator

Hi! > What I want to implement is the ability to allow arbitrary expressions on > the second operand, so instead of having to write something like this: I'm afraid there's a problem with this. Arbitrary expressions include constants, right? So what this means: var_dump($foo instanceof Bar); is

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 3:20 AM, Sanford Whiteman wrote: > > Nowhere did I suggest that the request verbs themselves (i.e. PUT and > POST) have the same intent. Just > > that the handling of multipart-form data is not specific to either one of > > those verbs. > > Define "handling." :/ > Specific

Re: [PHP-DEV] Lazy writing in the session, session-lock-ini, and bug #68331

Hi Andrey, The problem was "there was partial patch, while patch that overwrite it was not merged". I was confused. Offensive patch is removed for now already and this issue is closed. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net On Thu, Nov 6, 2014 at 5:42 PM, Andrey Andreev wrote: > Hi, > >

Re: [PHP-DEV] New Standardized HTTP Interface

On Thu, Nov 6, 2014 at 2:44 AM, Sanford Whiteman wrote: > > The HTTP specification doesn't restrict how the request body is encoded > > based on the request verb. > > I never said it did... please don't put words in my mouth. > > As Will notes, you're sidestepping the point, which standards-savvy

Re: [PHP-DEV] Lazy writing in the session, session-lock-ini, and bug #68331

Hi, On Thu, Nov 6, 2014 at 4:02 AM, Yasuo Ohgaki wrote: > HI all, > > On Thu, Nov 6, 2014 at 6:30 AM, Yasuo Ohgaki wrote: > >> On Wed, Nov 5, 2014 at 10:54 AM, Damian Wadley wrote: >> >>> Apparently this caused >>> problems for some people as they made 68331 a few days ago. >>> >> >> Just a qui

Re: [PHP-DEV] Lazy writing in the session, session-lock-ini, and bug #68331

Hi Yasuo, On Thu, Nov 6, 2014 at 3:42 AM, Yasuo Ohgaki wrote: > Hi Andrey, > > On Thu, Nov 6, 2014 at 8:23 AM, Andrey Andreev wrote: >> >> Short-term fix for 5.6 is obviously to revert the commit. I was vocal >> mostly because of principle at the time, but this issue is an example >> why. > > >

Re: [PHP-DEV] New Standardized HTTP Interface

> Nowhere did I suggest that the request verbs themselves (i.e. PUT and POST) > have the same intent. Just > that the handling of multipart-form data is not specific to either one of > those verbs. Define "handling." :/ "Handling" as in "interpreting multipart/form-data as key-value pairs": a sp