[PHP-DEV] Re: [VOTE] Voting opens for str_starts_with and ends_with function

Hello, I closed voting on the RFC page today and updated the main RFC page. The RFC was approved by 51 votes to 4. I assume the next step is to get the github PR approved and merged. Thanks, Will On 2020-04-19 22:58, w...@wkhudgins.info wrote: Hello, I have opened voting for the

[PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with function

Hello, I have opened voting for the str_starts_with and str_ends with RFC. The voting will be open until two weeks from now, 2020-05-04. RFC: https://wiki.php.net/rfc/add_str_starts_with_and_ends_with_functions Please vote, thanks! -Will -- PHP Internals - PHP Runtime Development Mailing

Re: [PHP-DEV] RFC Raised for str_starts_with and str_ends_with

h_ci() functions The second function should probably be str_ends_with() :) Nikita Hi Will, First, thank you for re-working on this, I would love to see it happen! :) Nevertheless, apart from some typos (already reported), I still think the RFC needs a "Motivation" section with act

Re: [PHP-DEV] RFC Raised for str_starts_with and str_ends_with

arts_with and str_ends_with functionality again. This is a simple but highly desired functionality for PHP. I think you mean PHP 7.4 here. PHP 8.0 is not yet released, and not in feature freeze either. > Add str_starts_with, and str_starts_with_ci() functions The second function should

[PHP-DEV] RFC Raised for str_starts_with and str_ends_with

and narrowed the new RFC to only propose str_starts_with and str_ends_with. Thanks, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

nd_functions) . > > You can access the voting page here: > https://wiki.php.net/rfc/add_str_begin_and_end_functions/vote > > I have never set up a vote on doku-wiki so please let me know if I made > the vote incorrectly! > > Thanks, > > Will > As we're already tw

Re: [PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

Sure, that brings some issues along with it, but that is as much a strength of the language as it is a challenge. Adding a common task like starts_with and ends_with seems like a reasonable thing to do. Thanks, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [VOTE] Voting opens for str_starts_with and ends_with functions

Following up on this, I plan to leave voting open for a full 15 days, until July 20, 2019 Anywhere-on-Earth (AOE) time. If there are issues with this time, let me know. Thanks, Will On 2019-07-04 22:13, w...@wkhudgins.info wrote: Hello all, After 15 days of discussion I have opened up

[PHP-DEV] [VOTE] Voting opens for str_starts_with and ends_with functions

please let me know if I made the vote incorrectly! Thanks, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

I have updated the RFC here https://wiki.php.net/rfc/add_str_begin_and_end_functions to reflect changes from the mailing list discussions. I will promptly open voting on this RFC. -Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

Nikita: I like the idea of splitting the mb_* versions from the main vote...I'll have to see how to do that in the docu-wiki GUI but I like the idea! CHU: I will add a note that some userland functions may not be compatible with this change although I don't think that should be a s

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

These are good points. Originally my RFC called for less functions but based on feedback I added the others. My proposal: take the RFC as-is to a vote. If it fails, I will raise another RFC for a vote that will just contain the two basic functions: str_begins and str_ends. Thanks, Will On

[PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

email. -Will On 2019-06-18 14:45, w...@wkhudgins.info wrote: Hello all, I submitted this RFC several years ago. I collected a lot of feedback and I have updated the RFC and corresponding github patch. Please see the RFC at https://wiki.php.net/rfc/add_str_begin_and_end_functions and the github

[PHP-DEV] RFC Desite to move RFC add_str_begin_and_end_functions to a vote

addressed many concerns (order of arguments, name of functions, multibye support, etc). I plan to move this RFC to a vote in the coming weeks. Thanks, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

/manage/github.php which takes care of this. > > We try to limit people with direct access to github repos as direct > pushes there (or clicking the merge button) will break syncing with > git.php.net (to be precise: a push on git.php.net does a force push to > github, which might d

[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 Posted for str_begins and str_ends functions

/add_str_begin_and_end_functions The github PR may be found at: https://github.com/php/php-src/pull/2049 Hope to be hearing about this, Will Firstly, the argument ordering is the wrong way round for a string function. String functions — especially search-related ones — are haystack, needle (see strpos

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

n the proposed functions and existing PHP string functions. The goal is to make these functions feel natural and add functionality to the language without cluttering it up. Thanks, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Posted for str_begins and str_ends functions

in is more readable. Therefore, I think it would be better to implement: boolean str_begin(string $search_value, string $str) boolean str_ibegin(string $search_value, string $str) boolean str_end(string $search_value, string $str) boolean str_iend(string $search_value, string $str) This is much m

[PHP-DEV] RFC Posted for str_begins and str_ends functions

/2049 Hope to be hearing about this, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] RFC Karma Request

. True str_begins and str_ends would do check if a string begins or ends with a string of n characters. Regards, -Will On 2016-07-26 19:39, Davey Shafik wrote: Will, Now that we have generalized support for negative string offsets you can now just do: $string = "/foo/bar/bat/"; if

Re: [PHP-DEV] RFC Karma Request

ful information. Please get back with me with your thoughts. Thanks, Will On 2016-07-26 16:09, David Rodrigues wrote: Questions: 1. Have you talked with this list about the terms of you suggestions? (like str_begins, str_starts, strstarts, strbegins, str_ends, strends...) Is yes, sorry, I do no

[PHP-DEV] RFC Karma Request

core PHP copy. Thanks, Will -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

nt { return 55.5; } var_dump(blah()); Will return 55. It's a little different with properties, but what are your thoughts on this runtime conversion? > > 2. This whole temporary nullability situation, where unset properties > will error on attempted usage if not set. Should they

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

>>> make it only installable via PECL). > >>> > >>> In the interim, I'll be developing a (MIT licensed) decryption-only > >>> userland implementation of the mcrypt ciphers so people can migrate their > >>> code towards something

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

t;>> such case, except for very generic API giving access to the basic >>> request, its fields and supporting basic URL/MIME parsing. >> >> Even just parsing JSON isn’t as simple as it sounds. There are several >> things users might like to configure, several ways to

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

two options to contrast > between their trade offs. I think that handling this stuff in PHP is likely > to prove more efficient. What I hope to gain from this discussion is the > optimal path to that implementation and what it would look like. Because > the parts that really matter are ju

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

eady said with every single one > of your responses attempting to derail this discussion into a matter that > concerns FIG or PSR or whatever other third party concern that is > tangentially related to the word HTTP is something I will not stand for. While not too specific to Rowan, reitera

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

someone else to merge it, and the request is probably sticking around > because the patch isn’t yet fixed. The exception is pull requests for > accepted RFCs by authors who lack commit access: for these, someone will need > to go and merge them. > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >

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

collation option. For example, if the solution for collation in general is to use a built-in class or similar function, we will run into these issues. However, if the assumption is we will allow collations to be configurable - or assume Unicode in some fashion, the weight of this effort

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

the faintest. > > Also, removing $_GET and $_POST is a *massive* backwards-compatibility break. > I would vote against this proposal and I hope everyone else will join me in > doing so, for that reason alone. > > Please, don’t completely break every single PHP site I’ve ever written. :(

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

g __toKey instead or any >>> reasonable alternative, we may also include a couple of options in the >>> vote if that will be a point of disagreement. >> >> I like this idea with custom hash implementation because spl_object_hash() >> is not reliable when objects are qu

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

id in the RFC, evidence that so many languages > implement it shows that this use case is quite real. Of course, you can > always default to spl_object_hash, but now you have control over it. Thank you for your clarity. With this new approach, wouldn’t we best be served by renaming/deprec

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

nable scenarios, if something is wrong or you have ideas how to > make it better please tell. > > The name __hash is not final, I am open to using __toKey instead or any > reasonable alternative, we may also include a couple of options in the > vote if that will be a point of disagre

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

tty easy as it was >> with commas :) >> It is absolutely backwards compatible (you can use `function` or you can not >> use it). Here's the patch: https://gist.github.com/nikita2206/4988075 >> >> If people will welcome this proposal, I would need some ka

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

er including a > heavily >> simplified version of APC or writing a new one. >> >> One thing I can guarantee is that if we add it to core in its current > condition it >> will delay 5.5 by 6+ months if not longer. > > There's another option. We have t

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

In the PHP source directory, look at ext/mysqlnd/mysqlnd.h. This will provide you with a C-level API. > > here is my code: > > PHP_FUNCTION(ig_connect_to_ > database) > { > zval fname, *args[3], dbLink; > zval sel

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 gene

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

e issue. There are a couple of issues with this approach, though. First, it forces you to make multiple calls to the server when you actually only need to escape input. Second, and most important in my case, when using middleware like pgbouncer, it's not possible to use true prepared

[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

is not lossy. >>> >> Yes it is! You can't go back from an UTC offset to a timezone string. >> Hence: lossy. >> > > Exactly ... > > Will - if you are displaying a date, and then looking for a UTC time 6 > months later you need the daylight saving settin

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

ng purposes as we'll never pick the "right" format to use in >> everyone's code. When needing to set the "default" (read: >> per-instance) string format with something like setToStringFormat() or >> whatever, that becomes*more* work than just calling

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

RFC a look. - Will

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

or several years the comparison would > be better. With register globals, a good alternative (the $_ > variables) have been around for many years. With traits, a good > alternative has been around for a few months. I think the point > of mentioning register globals is just to say &qu

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

$_REQUEST is a smash together of $_GET, $_POST > > > and $_COOKIE, in that order but the php.ini directive can change it. > > > Hence there's no way of knowing if $_REQUEST['password'] came from > > > $_COOKIE, $_POST, or $_GET, and worse, if two values in

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

ce there's no way of knowing if $_REQUEST['password'] came from > $_COOKIE, $_POST, or $_GET, and worse, if two values in those source > arrays have the same key $_REQUEST will overwrite them. $_REQUEST to > be honest, is a lame shortcut and bad idea almost on par with &

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

On Monday, January 2, 2012, JS wrote: > I think the proposed syntax will create a lot of code readability issues. > Have you considered an alternate syntax: > What readability issues? The proposed syntax matches that of C# and Java. The idea is to use a syntax already familia

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

Also, the RFC will be changing tonight/tomorrow'ish to take procedures (functions) into account as well. I know there are many who want to address the additional "types" to hint (e.g. scalar keyword), but I would like to focus discussion of the RFC to its current state - which

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

Scalars will not be supported as type hints. There was talk of a "scalar" token added for validation in that category, but it does NOT need to be supported for return type hinting to be included. Return type hints are following the same logic as parameter type hints and should be

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

I have updated the RFC and patch to reflect not allowing null to be returned unconditionally. With the current patch, I have not added any type of indicator to allow null to be returned at all. This will allow us to discuss things one at a time and determine whether we actually want an

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

  1   2   >