Re: [PHP-DEV] Re: GitHub and Extensions

Thanks, Johannes. I’ve closed that issue out. Please feel free to turn issues off when you’re able! > On Oct 7, 2017, at 7:45 AM, Johannes Schlüter wrote: > >> On Fr, 2017-10-06 at 20:11 +0200, Christoph M. Becker wrote: >> >> Not sure about issues, though. Probably these shouldn't even be >>

[PHP-DEV] GitHub and Extensions

option for GitHub extension maintainers? If so, both PHP and GH username is willfitch. Thanks, Will Fitch

Re: [PHP-DEV] [RFC Discussion] Typed Properties

On Wed, Mar 16, 2016, at 11:36 AM, Phil Sturgeon wrote: > Hello everyone, > > I have completed the draft for an RFC, to add Typed Properties. The > patch has been written by the one and only Joe Watkins. > > https://wiki.php.net/rfc/typed-properties > > I would really appreciate constructive f

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt

On Tue, Mar 15, 2016, at 12:18 PM, Ferenc Kovacs wrote: > On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski > wrote: > > > On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs wrote: > > > >> > >> > >> On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski > >> wrote: > >> > >>> Hi PHP team, > >>> > >

Re: [PHP-DEV] segfault in ini_lex() in 7.0.3

On Wed, Mar 9, 2016, at 03:51 PM, Adam Baratz wrote: >> Can you provide the INI (minus secure info) and script that generates >> this? > > Unfortunately, I haven't been able to isolate what's causing this. It > seems to occur on "complex enough" pages. Which could mean one of the > (many) extension

Re: [PHP-DEV] segfault in ini_lex() in 7.0.3

On Wed, Mar 9, 2016, at 01:28 PM, Adam Baratz wrote: > I got a core dump with this output: Can you provide the INI (minus secure info) and script that generates this? > > Cannot access memory at address 0x9 > Cannot access memory at address 0x1 > > #0 0x00654a6d in ini_lex (ini_lval=

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 <mailto:willfi...@php.net>> wrote: > > Sherif - I’m just going to be straight here. I haven’t seen support for your > proposal at all in this thread.

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 Nov 5, 2014, at 10:00 PM, Sherif Ramadan wrote: > > > > On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch wrote: > > > > Easy - you have no idea what the input type is from PUT without checking the > incoming type. With POST, you know exactly what it

Re: [PHP-DEV] New Standardized HTTP Interface

> On Nov 5, 2014, at 9:23 PM, Sherif Ramadan wrote: > > On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds wrote: > >> >>> On 6 Nov 2014, at 01:29, Sherif Ramadan wrote: >>> >>> So you're actually describing two semi-different problems here. One is >> that PHP doesn't actually inform you of the

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 31, 2014, at 4:51 PM, Sherif Ramadan wrote: > > On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch wrote: > >> >> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan >> wrote: >> >> >> >> On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch wrote:

[PHP-DEV] pecl/http RFC

I don’t want to restart any previous threads, but I’d like to get/restart the conversation going with the pecl/http RFC: https://wiki.php.net/rfc/pecl_http . Recent conversations regarding https://wiki.php.net/rfc/http-interface

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 31, 2014, at 4:21 PM, Sherif Ramadan wrote: > > > > On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch <mailto:willfi...@php.net>> wrote: > > > > While not too specific to Rowan, reiterating the pecl/http approach is > indirectly what your ask

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 31, 2014, at 4:05 PM, Sherif Ramadan wrote: > > On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins > wrote: > >> Sherif Ramadan wrote on 31/10/2014 18:52: >> >>> This RFC is about core PHP and I really don't care how >>> many competing ideas exist out there that are closely or mildly rel

Re: [PHP-DEV] [RFC] GitHub Pull Requests Triage Team

> On Oct 31, 2014, at 12:10 PM, Andrea Faulds wrote: > > >> On 30 Oct 2014, at 21:57, John Bafford wrote: >> I would like to propose the creation of a team to triage the pull requests >> on GitHub, to help ensure that the pull requests are handled in a timely >> manner. I am also volunteerin

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 30, 2014, at 6:20 PM, Lester Caine wrote: > > On 30/10/14 17:42, Rowan Collins wrote: >> The use case which came up recently was UString objects, which can >> easily be converted to and from plain PHP strings, but would be useful >> as keys in their own right. With current PHP you could

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 30, 2014, at 3:28 PM, Andrea Faulds wrote: > > >> On 30 Oct 2014, at 19:51, Will Fitch wrote: >> >> My only concern at this point is the default value of the hash. If we were >> to use spl _object_hash, we could be setting a precedence that a hash

Re: [PHP-DEV] New Standardized HTTP Interface

> On Oct 30, 2014, at 4:15 PM, Andrea Faulds wrote: > > >> On 30 Oct 2014, at 20:49, Sherif Ramadan wrote: >> >> No, the interface makes it possible to implement your own behavior, but it >> does not prevent PHP from implementing default behavior. In that PHP would >> implement its own Htt

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 30, 2014, at 1:32 PM, Stas Malyshev wrote: > > Hi! > >> Put another way, I think a key question here is: >> >> class Foo { >> public $bar; >> } >> >> $a = new Foo; >> $a->bar = 'baz'; >> $b = new Foo; >> $b->bar = 'baz'; >> >> $arr[$a] = true; >> $arr[$b] = true; >> >> >> Does

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 30, 2014, at 2:13 AM, Christian Stoller wrote: > > > From: Alexander Lisachenko [mailto:lisachenko...@gmail.com], Sent: Monday, > October 27, 2014 11:18 AM > >> Hello, internals! >> >>> The name __hash is not final, I am open to using __toKey instead or any >>> reasonable alternativ

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 27, 2014, at 1:36 AM, Stas Malyshev wrote: > > Hi! > >> It seems __toScalar might be a good name, this is what the method >> actually does, the engine then coerces to a type suitable for use as a >> key, but you can return a double. It might be more forward thinking >> therefore to use

Re: [PHP-DEV] New globals for PUT and DELETE

> On Oct 26, 2014, at 10:38 PM, Sanford Whiteman wrote: > >> pecl/http is available > > To a degree, but no binaries for Windows == not a universal > prescription. Mailparse by contrast does have a shipping DLL. I’m confused. pecl/http does have Windows binaries: http://windows.php.net/downlo

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 26, 2014, at 9:43 PM, Stas Malyshev wrote: > > Hi! > >> I’m trying to wrap my head around a real-world use-case with this. >> We have spl_object_hash, which effectively provides a unique hash for > > This hash has nothing to do with object's contents. But imagine number > GMP("42") an

Re: [PHP-DEV] [RFC] Using objects as keys

> On Oct 26, 2014, at 8:37 PM, Stas Malyshev wrote: > > Hi! > > I would like to present to your attention an RFC about using object as keys: > > https://wiki.php.net/rfc/objkey > Hi Stas! I’m trying to wrap my head around a real-world use-case with this. We have spl_object_hash, which eff

Re: [PHP-DEV] New globals for PUT and DELETE

> On Oct 26, 2014, at 5:00 PM, Park Framework wrote: > > 2014-10-26 23:24 GMT+02:00 Florian Margaine : >> I think Rasmus made it clear what the original naming meant: it were form >> methods, not related at all to HTTP methods. > > Yes, this would be logical to have access to the input data, as

Re: [PHP-DEV] New globals for PUT and DELETE

> On Oct 26, 2014, at 4:21 PM, Stas Malyshev wrote: > > Hi! > >> The only way to do this in PHP now is write a userland function that parses >> multipart form data, which is non-trivial. I had written one, but would > > It is true that PUT data need to be parsed, however it is not true you > h

Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed

On Thu, Mar 7, 2013 at 7:10 AM, Bob Weinand wrote: > Am 7.3.2013 um 00:32 schrieb Stas Malyshev : > > > Hi! > > > >> RFC updated. > >> > >> Any other comments about this RFC? > > > > Could you provide a use case for this - which practical value this has? > > > > It also still contains factually i

Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed

On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand wrote: > Am 6.3.2013 um 22:50 schrieb Will Fitch : > > On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand wrote: > >> Am 06.03.2013 um 22:39 schrieb "Will Fitch" : >> >> On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand w

Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed

On Wed, Mar 6, 2013 at 4:40 PM, Ferenc Kovacs wrote: > On Wed, Mar 6, 2013 at 10:38 PM, Ferenc Kovacs wrote: > > > > > > > > > On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand > wrote: > > > >> Hi! > >> > >> As this seem to require a RFC, here is it: > >> > >> https://wiki.php.net/rfc/unset_bool >

Re: [PHP-DEV] [RFC] unset(): return bool if the variable has existed

On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand wrote: > Hi! > > As this seem to require a RFC, here is it: > > https://wiki.php.net/rfc/unset_bool I'm not a fan of this change, but if it's going to be discussed, the RFC should include baseline and RFC change benchmarks. > > > Please feedback, >

Re: [PHP-DEV] Dropping requirement for `function` keyword for methods in classes/interfaces/etc

On Feb 19, 2013, at 6:01 PM, Zeev Suraski wrote: > Are we really trying to look under ground now for ways to change the > language syntax? Agree 100%. Not to mention, I plan on eventually convincing enough people to replace that keyword with a type hint ;) > > Unless there's a strong case to

Re: [PHP-DEV] [RFC] Allow trailing comma in function call argument lists

On Feb 19, 2013, at 8:00 AM, Sara Golemon wrote: > On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink > wrote: >> Just a question from one of the lingering listeners: would this change also >> ease the `skipping` of default values for parameters? (as discussed for RFC >> https:

Re: [PHP-DEV] Purpose of voting

On Jan 28, 2013, at 2:14 PM, Anthony Ferrara wrote: > Hey all, > > After reading the Voting Periods email thread, I'm left wondering a simple > question (which has a difficult answer): > > What should we be voting on when voting on an RFC: on the RFC proposed > feature, or on the patch itself?

Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0

On Jan 25, 2013, at 11:52 AM, Julien Pauli wrote: > On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch wrote: > > On Jan 25, 2013, at 11:25 AM, Zeev Suraski wrote: > > >> Either by a number of people stepping up to help with the existing APC > > code, or > >> pe

Re: [PHP-DEV] HEADS UP: Upcoming Feature Freeze for PHP 5.5.0

On Jan 25, 2013, at 11:25 AM, Zeev Suraski wrote: >> Either by a number of people stepping up to help with the existing APC > code, or >> perhaps more realistically making it a priority in PHP 5.6 to streamline > the >> engine and the executor for opcode caching and either including a > heavily

Re: [PHP-DEV] new FTP function

On Jan 18, 2013, at 9:53 AM, KISE wrote: > Hi > > II would like to see "ftp_dir_exists()" function in PHP, right now its > kinda unreasonable to expect people to use hacks such as "is_dir()" and > having to re-authenticate just to check if the dir exists, I also dont > think its good idea to us

Re: [PHP-DEV] a simple question about PHP extension: using user function in my own extension

On Wed, Dec 5, 2012 at 6:18 AM, Amir wrote: > Hi > I am trying to build an PHP extension for my personal project. > For some reason. I want to build some part of my project with extension. > So, I can make a connection via my extension as you can see below my c++ > source code. > > Cause of poor

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Thu, Nov 15, 2012 at 3:11 PM, Rasmus Lerdorf wrote: > On 11/15/2012 12:08 PM, Will Fitch wrote: > > On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote: > > Actually, no it wouldn't. You still get the overhead of the error, > plus > > any custom err

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote: > On 11/15/2012 11:53 AM, Will Fitch wrote: > > On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev >wrote: > > > >> Hi! > >> > >>> Again, though, this is a long way down the road: toda

Re: [PHP-DEV] RFC: ext/mysql deprecation

On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev wrote: > Hi! > > > Again, though, this is a long way down the road: today's discussion is > > purely about deprecation. > > So these people using mysql-based code will have for years to live with > applications generating thousands of warnings and not

Re: [PHP-DEV] pdo_pgsql Boolean Issues

This request was given a +1 from Wez - does anyone else want to provide feedback? If not, can we get it merged to trunk and queued for release? On Wed, Oct 3, 2012 at 2:02 PM, Will Fitch wrote: > Going to bump this thread. > > https://bugs.php.net/bug.php?id=62593 > https://github

Re: [PHP-DEV] pdo_pgsql Boolean Issues

ez Furlong wrote: > I'll make a point of reviewing this over the weekend; thanks! > > --Wez. > > On Thu, Sep 20, 2012 at 10:09 AM, Will Fitch wrote: > > Thanks, Pierre - The PR can be found at > > https://github.com/php/php-src/pull/198 >

Re: [PHP-DEV] pdo_pgsql Boolean Issues

Thanks, Pierre - The PR can be found at https://github.com/php/php-src/pull/198 On Tue, Sep 18, 2012 at 3:56 AM, Pierre Joye wrote: > hi Will, > > On Mon, Sep 17, 2012 at 7:45 PM, Will Fitch wrote: > > > While I've spent the better part of a week trying to determine t

[PHP-DEV] pdo_pgsql Boolean Issues

Hi, all - There's a bug in the current version of 5.3 and 5.4 with pdo_pgsql and boolean PDO types. Here's a summary of the issue: The following cases cause pgsql boolean types to be converted to an incompatible (long) format: 1. PQprepare is not available (HAVE_PQPREPARE is undefined). This ha

[PHP-DEV] Is Git Down?

I haven't seen a maintenance notification, and it appears git.php.net may be down. Anyone else able to reproduce this?

Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?

On Fri, Sep 7, 2012 at 1:24 PM, Mark wrote: > On Fri, Sep 7, 2012 at 8:22 AM, Lester Caine wrote: > > Stas Malyshev wrote: > >> > >> Hi! > >> > >>> I wasn't assuming. I was outright making a factual statement. I never > >>> made any implications of the intellectual levels of those implementing >

Re: [PHP-DEV] Why are the PHP namespaces different compared to C++?

On Fri, Sep 7, 2012 at 1:24 PM, Mark wrote: > On Fri, Sep 7, 2012 at 8:22 AM, Lester Caine wrote: > > Stas Malyshev wrote: > >> > >> Hi! > >> > >>> I wasn't assuming. I was outright making a factual statement. I never > >>> made any implications of the intellectual levels of those implementing >

Re: [PHP-DEV] On BC and interfaces

On Thu, Sep 6, 2012 at 2:43 PM, Kris Craig wrote: > On Tue, Sep 4, 2012 at 12:15 AM, Stas Malyshev >wrote: > > > Hi! > > > > Given many discussions on the list about changing stuff in PHP, I'd like > > to bring everybody's attention to comment by Linus Torvalds in this > > topic: https://plus.go

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Wed, Sep 5, 2012 at 4:14 AM, Lester Caine wrote: > Will Fitch wrote: > >> Hi, Lester - I'll update the patch and RFC to include this format. This >> is the >> format I'll use unless others have a better approach: >> >> 2012-09-01T00:00:00-0500

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 8:28 AM, Lester Caine wrote: > Derick Rethans wrote: > >> You have an accurate representation of the ISO format - which does not >>> >specify the string representation of a timezone, but rather the offset >>> of >>> >UTC. This is not lossy. >>> >> Yes it is! You can't go b

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 8:09 AM, Lars Strojny wrote: > Hi Pierre, hi Will, > > Am 03.09.2012 um 13:57 schrieb Pierre Joye : > > > hi Will, > > > > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: > >> On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: >

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye wrote: > hi Will, > > On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wrote: > > On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: > > > >> As far as I can tell, there's no standard which uses the Olson database > &g

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey wrote: > On 3 September 2012 17:36, Andrew Faulds wrote: > > Ryan McCue wrote: > >>What about ISO8601 with the Olson timezone suffixed? > >> > >>2012-09-02T18:17:36+0100 (Europe/London) > >>2012-09-02T18:19:05+0100 (Africa/Niamey) > >> > > > >

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue wrote: > As far as I can tell, there's no standard which uses the Olson database > to specify the timezone, so we'd have to create one. > > What about ISO8601 with the Olson timezone suffixed? > > 2012-09-02T18:17:36+0100 (Europe/London) > 2012-0

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Mon, Sep 3, 2012 at 4:16 AM, Derick Rethans wrote: > On Sun, 2 Sep 2012, Will Fitch wrote: > > > On Sep 2, 2012 6:08 PM, "Lester Caine" wrote: > > > > > > Peter Cowburn wrote: > > >> > > >> Finally, why should "echo $dat

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Sep 2, 2012 6:08 PM, "Lester Caine" wrote: > > Peter Cowburn wrote: >> >> Finally, why should "echo $datetime;" be expected to work at all, >> since 95% of the time it's only going to be echo'd plain like that for >> debugging purposes as we'll never pick the "right" format to use in >> everyon

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Sep 2, 2012 4:39 PM, "Andrew Faulds" wrote: > > On 02/09/12 18:20, Derick Rethans wrote: >> >> >> No it's not unambigious: >> >> $ php -r 'date_default_timezone_set("Europe/London"); echo date_create()->format(DateTime::ISO8601), "\n";' >> 2012-09-02T18:17:36+0100 >> >> $ php -r 'date_default_t

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev wrote: > Hi! > > > I would like to officially introduce an RFC with a patch to implement > > __toString to DateTime. This is a commonly requested feature that goes > > unanswered mostly because of the inability to agree on a default pattern. > > This

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Sat, Sep 1, 2012 at 4:54 PM, Derick Rethans wrote: > On Sat, 1 Sep 2012, Will Fitch wrote: > > > I would like to officially introduce an RFC with a patch to implement > > __toString to DateTime. This is a commonly requested feature that goes > > unanswered mostly bec

Re: [PHP-DEV] RFC for Adding __toString to DateTime

On Sat, Sep 1, 2012 at 6:36 AM, Pierre Joye wrote: > hi Will, > > On Sat, Sep 1, 2012 at 12:14 PM, Will Fitch wrote: > > I would like to officially introduce an RFC with a patch to implement > > __toString to DateTime. This is a commonly requested feature that goes

[PHP-DEV] RFC for Adding __toString to DateTime

I would like to officially introduce an RFC with a patch to implement __toString to DateTime. This is a commonly requested feature that goes unanswered mostly because of the inability to agree on a default pattern. In short, the patch uses the ISO-8601 format as the default pattern. The pattern

Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach

You're right. My apologies. On Tue, Aug 28, 2012 at 1:11 PM, Andrew Faulds wrote: > On 28/08/12 18:07, Will Fitch wrote: > >> I just noticed the RFC is listed in the Accepted category. Did something >> change with the 2/3rds voting requirement? Right now, it stands at

Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach

t; On Sun, 2012-08-26 at 21:07 +0300, Yahav Gindi Bar wrote: > >> On Sun, Aug 26, 2012 at 9:00 PM, Will Fitch wrote: > >> > >> > Maybe the simplest solution is we have a minimum participation rate > before > >> > voting can be closed? > >> >

Re: [PHP-DEV] Re: [VOTE]Call for voting: support use list in foreach

Maybe the simplest solution is we have a minimum participation rate before voting can be closed? On Sun, Aug 26, 2012 at 1:58 PM, Stas Malyshev wrote: > Hi! > > > Only people with a VCS account (or voting group) can vote. > > OK, I stand corrected then, but participation rate is still awfully low

Re: [PHP-DEV] re: removing an item from an array

Please let this die until someone is serious enough to come up with an rfc. This has been nothing but counterproductive arguing. If someone feels strongly about it, write an rfc then we can discuss? On Aug 20, 2012 7:53 PM, "Yasuo Ohgaki" wrote: > Hi, > > 2012/8/21 Herman Radtke : > >>> May be we

Re: [PHP-DEV] removing an item from an array

I like that chose 42 for the value. You win, and I completely agree. On Wed, Aug 15, 2012 at 4:22 PM, Stas Malyshev wrote: > Hi! > > > How come there is no straight-foward obvious way to simply remove a given > > value from an array? > > The same reason there's no simple way to undefine variable

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context

On Mon, Jul 30, 2012 at 3:11 PM, Todd Ruth wrote: > On Mon, 2012-07-30 at 19:31 +0200, Gustavo Lopes wrote: > > https://wiki.php.net/rfc/incompat_ctx > > > > An RFC for deprecating and removing $this from incompatible context. > > > > Comments are welcome. > > > > -- > > Gustavo Lopes > > I'm jus

Re: [PHP-DEV] [RFC] Remove calls with incompatible Context

I think this is a good idea. I agree with the intention of throwing E_DEPRECATED in 5.5, but what do you propose happen afterwards? Throw a fatal error? I would just like to make "removing (in the next version)" a little more definitive. On Mon, Jul 30, 2012 at 1:31 PM, Gustavo Lopes wrote: > h

Re: [PHP-DEV] $_PARAMETERS Super Global Object

On Friday, February 24, 2012 at 5:16 PM, Larry Garfield wrote: > On 2/24/12 3:28 PM, Richard Lynch wrote: > > On Wed, February 22, 2012 9:10 am, Michael Morris wrote: > > > $_REQUEST does nothing of the sort, and it's use is dangerous in > > > RESTful architecture. $_REQUEST is a smash together of

Re: [PHP-DEV] $_PARAMETERS Super Global Object

myVar']; > To get it's filtered value I'd use $_PARAMETERS->get->filtered['myVar'] > To set those filters I'd use $_PARAMETERS->get->setFilters( $filters ); > > As I said before, you should add a RFC entry if you want this taken seriously.

Re: [PHP-DEV] $_PARAMETERS Super Global Object

at as well. That said, if you're serious about the idea, a RFC would be helpful in understanding the full extent that you're suggesting. -- Will Fitch On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: > Before writing up a full RFC I want to put out a f

[PHP-DEV] Re: Return Type Hinting for Methods RFC

{ > > } > > I don't see how you feel that makes things more legible. Again, developers familiar with languages outside of PHP are already familiar with the proposed syntax. If the majority of folks out there would rather see this approach as opposed to the C#/Java style, I'

Re: [PHP-DEV] Return Type Hinting for Methods RFC

nctions at the same time. > > To be honest I don't know even if that's possible. So, it's just a thought. > > 2011/12/24 Will Fitch > >> The RFC and patch has been updated to include the nullable functionality >> that addresses the concerns mentioned b

Re: [PHP-DEV] Return Type Hinting for Methods RFC

List > Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC > > I'm sorry but even though I liked that RFC, I'd like to ask about type > hinting through annotations. Has anyone considered that? I think that it > would be nice because it also docs the functions at the same

Re: [PHP-DEV] Return Type Hinting for Methods RFC

The RFC and patch has been updated to include the nullable functionality that addresses the concerns mentioned by Stas. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 5:02 PM, Will Fitch wrote: > I have updated the RFC and patch to reflect not allowing null to be retur

Re: [PHP-DEV] Return Type Hinting for Methods RFC

11/12/23 John Crenshaw > > From: Will Fitch [mailto:will.fi...@gmail.com] > > > > I would like to take this opportunity to query on a consensus: > > > > Would you prefer to allow methods with type hinted return values to return > > null at will, or add a marker

Re: [PHP-DEV] Return Type Hinting for Methods RFC

Sent from my iPhone On Dec 23, 2011, at 6:32 PM, "André Rømcke" wrote: 2011/12/23 John Crenshaw > > From: Will Fitch [mailto:will.fi...@gmail.com] > > > > I would like to take this opportunity to query on a consensus: > > > > Would you prefer to allow m

Re: [PHP-DEV] Return Type Hinting for Methods RFC

indicator added. https://wiki.php.net/rfc/returntypehint2 On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: > On 12/23/11 13:34, "Will Fitch" wrote: > > >> There's still the matter of whether allowing null to be returned, >> regardless of the situation, or

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 23, 2011, at 4:29 PM, Robert Williams wrote: > On 12/23/11 13:34, "Will Fitch" wrote: > > >> There's still the matter of whether allowing null to be returned, >> regardless of the situation, or using another token to identify that >> it could

Re: [PHP-DEV] Return Type Hinting for Methods RFC

Im personally not a fan of declaring multiple return values. This defeats the purpose of being more strict. If your method may return different values outside of the declared type, then using the standard "function" keyword would signify mixed. There's still the matter of whether allowing null to

Re: [PHP-DEV] Return Type Hinting for Methods RFC

I would like to take this opportunity to query on a consensus: Would you prefer to allow methods with type hinted return values to return null at will, or add a marker noting that it *may* return null? Example: Return null at will public ArrayIterator getIterator() { // something happened, w

Re: [PHP-DEV] Return Type Hinting for Methods RFC

I will update to take functions into consideration. Will let you know when the RFC/patch reflect it. On Dec 22, 2011, at 7:44 PM, Ángel González wrote: >> (I'm unsure about the T_DOUBLE_ARROW, although for parsing, I feel there >> should be some token there >> before the class name, though I'm u

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 7:33 PM, Ángel González wrote: > On 23/12/11 01:00, Will Fitch wrote: >> On Dec 22, 2011, at 6:28 PM, Stas Malyshev wrote: >>> In PHP, returning object if everything is OK and false if not is a very >>> common pattern. >>> Also, you

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 7:21 PM, Ángel González wrote: > On 23/12/11 00:08, Will Fitch wrote: >> Sent from my iPad >> On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote: >> >>> Your examples only show class methods with visibility qualif

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 7:55 PM, Stas Malyshev wrote: > Hi! > >> And in those cases, they would continue to use the keyword "function" >> and be considered unknown as they are today. > > Taking the most common case and ignoring it and saying "ok, then don't use > it" is not a good way to design a

Re: [PHP-DEV] Return Type Hinting for Methods RFC

Sent from my iPhone On Dec 22, 2011, at 7:14 PM, Stas Malyshev wrote: > Hi! > >> Are you suggesting not allowing null to be returned, or provide an >> indicator within the syntax that it may return null? PHP would be the >> first language I'm aware of that would do so in either case. > > No I a

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 6:28 PM, Stas Malyshev wrote: > Hi! > >> Most modern languages allow returning null in any case. This is a hail >> Mary in the event something happens, but throwing an exception is >> inappropriate. I see no reason to diverge from that. > > In PHP, returning object if everythi

Re: [PHP-DEV] Return Type Hinting for Methods RFC

Sent from my iPad On Dec 22, 2011, at 5:51 PM, "Ángel González" wrote: > Your examples only show class methods with visibility qualifyiers, and > looking at the changes to zend_language_parser.y > it seems as if would only be available for methods. Wouldn't return > hints be available for plain f

Re: [PHP-DEV] Return Type Hinting for Methods RFC

So, are we in agreement that, within the scope of this RFC, type hinting is going to be limited to and match parameter type hinting? On Dec 22, 2011, at 3:35 PM, John Crenshaw wrote: > From: Paul Dragoonis [mailto:dragoo...@gmail.com] > >> On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf wrote

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 3:06 PM, Stas Malyshev wrote: > Hi! > >> I'm going to have to disagree with you there. Type hinting DOES save >> me a LOT of effort in development. I can stop worrying about checking >> to make sure the parameter that I got is what I want it to be, and >> just use it. The

Re: [PHP-DEV] Scalar Type Hint

That's the way to do it. If you have an idea, such as this, write it up, and let's discuss. If we don't, we end up talking about things (like scalar type hinting) that has been beaten to death on more than 100 occasions (sarcasm, but not really...). We can then have a reference to point to sh

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 1:51 PM, Sebastian Bergmann wrote: > Am 22.12.2011 19:41, schrieb Rasmus Lerdorf: >> This is not a step forward. If the author of age_check() really doesn't >> want to accept type-juggled arguments, then it is easy enough to do a >> strict type check in the function itself. Th

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 1:50 PM, Paul Dragoonis wrote: > On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf wrote: > >> On 12/22/2011 07:08 AM, Keloran wrote: >>> i would love to see this expanded aswell (the way type hinting on >> function >>> variables was supposed to be), so that it could be >>> >

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote: > On 12/22/2011 07:08 AM, Keloran wrote: >> i would love to see this expanded aswell (the way type hinting on function >> variables was supposed to be), so that it could be >> >> string, int >> >> e.g. >> function int test(bool $tester) { >> if

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 10:18 AM, Oleg Oshmyan wrote: >> public function \Customer getCustomer(){ >> return $this->customer; >> } >> >> If the $customer instance variable is not declared with the type Customer >> then first of all IDE will not be able to spot an error, second compiler may >> have a

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On Dec 22, 2011, at 10:11 AM, Dmitri Snytkine wrote: > I think the return type hinting really depends on variable type hinting. > A simple example whould bea typical getter function > > public function \Customer getCustomer(){ > return $this->customer; > } The actual syntax would be: public

Re: [PHP-DEV] Return Type Hinting for Methods RFC

t; Ultra Logistics, Inc. > Phone: (888) 220-4640 x 2097 > Fax: (888) 795-6642 > E-Mail: dsnytk...@ultralogistics.com > Web: www.ultralogistics.com > > "A Top 100 Logistics I.T. Provider in 2011" > > > -Original Message- > From: Will Fitch [mailto

Re: [PHP-DEV] Return Type Hinting for Methods RFC

yet, this > feature exists already and should be part of the RFC, to be complete. > > Cheers, > > On Wed, Dec 21, 2011 at 6:22 PM, Will Fitch wrote: >> Hi Nikita, >> >> I didn't add that as it's not yet in production. As soon as things are >> finaliz

Re: [PHP-DEV] Return Type Hinting for Methods RFC

Dec 21, 2011 at 6:22 PM, Will Fitch wrote: >> Hi Nikita, >> >> I didn't add that as it's not yet in production. As soon as things are >> finalized and 5.4 is GA, I will gladly add the callable type hint. The >> change wouldn't be different from

Re: [PHP-DEV] Return Type Hinting for Methods RFC

o be sure on that. > > Nikita > > On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch wrote: >> Hello All, >> >> I would like to submit https://wiki.php.net/rfc/returntypehint2 into >> discussion. A link to the patch for this is provided and can be ran against >&g

  1   2   >