[PHP-DEV] Re: [RFC][Vote] New Curl URL API

[Mark Randall]

On 05/07/2022 00:34, Pierrick Charron wrote:

All recent discussions show that we are not even close to getting a
consensus on how the new CurlUrl OO API should be done. After changing my
mind 300 times in the last day, I decided to only propose the procedural
implementation that stays consistent with other functions of the ext/curl
to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
freeze in two weeks, this is I think the only approach that will not put us
in a potentially bad/harmful situation for a better future with ext/curl.



I'm voting no on this one based on the discussions from R11.

The deadline being close is not a good enough reason to rush a change 
like this that will be difficult to unwind later.


I agree with some of the other comments made that it would be preferable 
to come up with a more generic solution that can be used by multiple 
components rather than something specific to Curl.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Peter Cowburn]

On Mon, 4 Jul 2022 at 11:11, Jakub Zelenka  wrote:

> On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot 
> wrote:
>
> > Hi internals,
> >
> > If the rest also thinks the RFC is good to go, I suggest we start a vote
> > coming week.
> > As this is my first RFC, I'm not so sure how this typically gets kicked
> > off, so I'd like to know what I need to do!
> >
>
> You just need to change status in RFC to Voting and in voting section set
> the date range and add doodle poll - you can basically copy it from one of
> the open RFC's (see for example code in
> https://wiki.php.net/rfc/fetch_property_in_const_expressions ). Then you
> just need to send email to internals with subject prefixed with [RFC][VOTE]
> or similar. As noted you need to do it today or latest tomorrow. Feel free
> to let me know if you are too busy or something is not clear.
>
> I would recommend not to do any last time changes as in such case you
> should probably give an extra time for dicusion which means it won't make
> the feature freeze and will have to wait for another year. In my opinion it
> is good as it is. The tabs can be later added as an extra flag. If the flag
> is set, we could just change default value for indent to 1 and use tabs but
> it would be still possible for users to set indent size if they wish. I
> think that's something that makes most sense to me and doesn't impact the
> current RFC in any way.
>
> Regards
>
> Jakub
>

My thoughts might be firmly in the realms of "too little, too late" since
the vote is open already, so by all means choose to ignore.

Things that I would have liked to have seen in the RFC document:
* the mention/consideration of a user-specified indent string
  (even if under a "Rejected Features" section with some details about the
rejection)
* details on the new parameter's interaction with / dependency on
JSON_PRETTY_PRINT.
* related, details on what happens when the new parameter is used without
JSON_PRETTY_PRINT.
  (I'd personally like to have JSON_PRETTY_PRINT be implicitly added if the
new parameter is used, or it could
   raise an error, or it could be ignored as seems to be the case but isn't
explicltly mentioned)
* details on allowed values of the new parameter, e.g. what happens with
negative, or stupidly huge, values?
* some summary (more than none!) of discussion topics / design decisions
resulting from the mailing list thread(s)

The RFC currently states (the quote is two-thirds of the proposal text,
minus examples):

> By default, an indentation of 4 spaces will be applied, just like the
original json_encode behaviour with the JSON_PRETTY_PRINT option.
>
> When the indent parameter is passed a different value, an indentation of
N spaces will be applied.

Even after several readings of the proposal, I thought that you were
proposing that json_encode() always be pretty-printed and indented.

Even the examples weren't particularly helpful in correcting
that mis-reading. It took me far too long to understand (hopefully
correctly) that:
* "By default..." means "When the flags include JSON_PRETTY_PRINT and the
indent parameter is not passed (or 4 is passed)...".
* "When the indent parameter is passed..." really means "When the flags
include JSON_PRETTY_PRINT and the indent parameter is passed...".
* Any calls to json_encode() without JSON_PRETTY_PRINT, with or without the
indent parameter, behave identically to now.

The "Unaffected PHP Functionality" section only muddied the waters further:
"Normal usage ... of the json_encode function will not be affected, as
the default of 4 spaces will still be in effect."

My point being, I don't think this document was anywhere near ready... but
feel free to disagree.

Just to finish up, wouldn't it be nice to have the following?..

json_encode($value, indent: 2)

Regards,

Peter

[PHP-DEV] Re: [RFC][Vote] New Curl URL API

[Pierrick Charron]

Sorry, I forgot to include the RFC Url :
https://wiki.php.net/rfc/curl-url-api

Le lun. 4 juill. 2022, à 19 h 34, Pierrick Charron  a
écrit :

> Hi internals,
>
> I opened voting for the new Curl URL API as part of PHP8.2.
>
> All recent discussions show that we are not even close to getting a
> consensus on how the new CurlUrl OO API should be done. After changing my
> mind 300 times in the last day, I decided to only propose the procedural
> implementation that stays consistent with other functions of the ext/curl
> to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
> freeze in two weeks, this is I think the only approach that will not put us
> in a potentially bad/harmful situation for a better future with ext/curl.
>
> The vote will last for 2 weeks and end on 19th of July.
>
> Regards
> Pierrick
>

[PHP-DEV] [RFC][Vote] New Curl URL API

[Pierrick Charron]

Hi internals,

I opened voting for the new Curl URL API as part of PHP8.2.

All recent discussions show that we are not even close to getting a
consensus on how the new CurlUrl OO API should be done. After changing my
mind 300 times in the last day, I decided to only propose the procedural
implementation that stays consistent with other functions of the ext/curl
to target 8.2. I know this is not the ideal scenario, but with 8.2 feature
freeze in two weeks, this is I think the only approach that will not put us
in a potentially bad/harmful situation for a better future with ext/curl.

The vote will last for 2 weeks and end on 19th of July.

Regards
Pierrick

[PHP-DEV] Re: [RFC] [Under Discussion] Constants in traits

[shinji igarashi]

Hello!

I have updated the RFC for constants in traits to clearly state
that Enumerations can use traits having constants.
https://wiki.php.net/rfc/constants_in_traits

As I said before, if there is no further discussion, I will open
the voting tomorrow.

Thanks!

--
Shinji Igarashi

2022年7月2日(土) 10:30 shinji igarashi :
>
> Hello, everyone!
>
> I have updated the RFC for constants in traits to reflect the discussion at
> ML and answer some additional questions, as well as add sections on
> comparisons to other languages and future scope, and modify some
> sentences for clarity.
> https://wiki.php.net/rfc/constants_in_traits
>
> If there is no additional discussion, I will open the voting around
> 2022-07-05 22:00 (UTC) .
>
> Thanks!
>
> --
> Shinji Igarashi
>
> 2022年6月22日(水) 6:33 shinji igarashi :
> >
> > Hello everyone!
> >
> > I'd like to start a discussion on an RFC to allow defining constants in 
> > traits.
> > https://wiki.php.net/rfc/constants_in_traits
> >
> > I'm looking forward to your feedback, including corrections on English 
> > wordings.
> >
> > Thanks!
> >
> > --
> > Shinji Igarashi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Add json_encode indent parameter

[Tim Düsterhus]

Hi

On 7/4/22 20:23, Timon de Groot wrote:

I went with Jakub's advice and opened the vote, not getting into any
other adjustments to the RFC prior to opening it for vote.

The vote for the json_encode 'indent' parameter is now open. It will run
until 15 July.

RFC: https://wiki.php.net/rfc/json_encode_indentation.


Don't forget to move it into the "In voting phase" section at:

https://wiki.php.net/rfc

Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC][Vote] Add json_encode indent parameter

[Timon de Groot]

Hi internals,

I went with Jakub's advice and opened the vote, not getting into any 
other adjustments to the RFC prior to opening it for vote.


The vote for the json_encode 'indent' parameter is now open. It will run 
until 15 July.


RFC: https://wiki.php.net/rfc/json_encode_indentation.

Kind regards,

Timon

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

[Arnaud Le Blanc]

Hi,

On lundi 4 juillet 2022 11:47:03 CEST Nicolas Grekas wrote:
> I'm just wondering if there could be a way to enable the auto-capture
> optimization for arrow functions. Having three kinds of rules for capturing
> feels too much, especially when there are that subtles for short closures.
> Maybe a deprecation could be possible for affected arrow functions?

Yes. I will propose this after this RFC.

This is not included in the RFC because the optimization rarely have an impact 
on Arrow Functions (they rarely bind variables).

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

[Arnaud Le Blanc]

Hi,

On lundi 4 juillet 2022 12:04:59 CEST Marco Pivetta wrote:
> I ended up voting NO due to the fact that there is no mention of `$this`
> behavior changes ( https://externals.io/message/117888#117889 ) : I also
> disagree with NikiC's stance on this being the same construct as before (
> https://externals.io/message/117888#117897 ), so I really wanted to get rid
> of this constant memleak risk that we have in closures. I should have made
> my stance stronger, instead of letting the discussion thread die, but time
> is what it is.

Forgot to add this in Future Scope, sorry.

The RFC does NOT change the behavior of `$this`, so as to keep it small. This 
is something I personally want, but it can be done after this RFC, and the 
change could be applied to all function kinds.

> Unclear (to me) after looking at
> https://gist.github.com/arnaud-lb/d9adfbf786ce9e37c7157b0f9c8d8e13, is
> whether the optimizations are applied at compile time. It looks like the
> changes are inside the `Zend/Optimizer/`, and `zend_compile.c`, so perhaps
> the benchmarks are probably just worded in a confusing way.

Sorry for the confusion. I confirm that the optimizations are applied at 
compile time. The benchmarks measure the runtime effect of these 
optimizations.

> Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`,
> which is a potential design issue.

The Optimizer was moved to `Zend/Optimizer` earlier so that in the long term 
it could be used by the compiler pipeline directly (rather than as part of 
caching).

There are clear benefits in reusing the Optimizer here. Duplicating or 
reimplementing live variable analysis would increase maintenance cost, whereas 
by reusing the Optimizer's implementation we take profit of a fast and well 
tested implementation.

Greets,

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Jakub Zelenka]

On Mon, Jul 4, 2022 at 8:38 AM Timon de Groot  wrote:

> Hi internals,
>
> If the rest also thinks the RFC is good to go, I suggest we start a vote
> coming week.
> As this is my first RFC, I'm not so sure how this typically gets kicked
> off, so I'd like to know what I need to do!
>

You just need to change status in RFC to Voting and in voting section set
the date range and add doodle poll - you can basically copy it from one of
the open RFC's (see for example code in
https://wiki.php.net/rfc/fetch_property_in_const_expressions ). Then you
just need to send email to internals with subject prefixed with [RFC][VOTE]
or similar. As noted you need to do it today or latest tomorrow. Feel free
to let me know if you are too busy or something is not clear.

I would recommend not to do any last time changes as in such case you
should probably give an extra time for dicusion which means it won't make
the feature freeze and will have to wait for another year. In my opinion it
is good as it is. The tabs can be later added as an extra flag. If the flag
is set, we could just change default value for indent to 1 and use tabs but
it would be still possible for users to set indent size if they wish. I
think that's something that makes most sense to me and doesn't impact the
current RFC in any way.

Regards

Jakub

Re: [PHP-DEV] Re: PHP-8.1 branch seems broken

[Derick Rethans]

On Mon, 4 Jul 2022, Christoph M. Becker wrote:

> On 04.07.2022 at 10:16, Remi Collet wrote:
> 
> > In PHP 8.1:
> >
> > This branch is 1 commit ahead, 7 commits behind master.
> >
> >
> > This seems terribly wrong, looks like was merged from master
> > (NEWS file have 8.2 entries)
> >
> >
> > Can some GIT expert check and fix that ?
> 
> Derick is working on fixing the issue.  Since he will need to reset to
> the last good state, and force-push, everybody will have to fix their
> clones afterwards (reset and pull).  Please do not push to any branch
> until this is done.

Thanks to Tim we've rebuild the PHP-8.1 branch. You will only have to 
reset the PHP-8.1 branch, with the following:

git fetch
git checkout PHP-8.1
# Backup local changes
git reset --hard origin/PHP-8.1
# Reapply local changes

Before you push anything, please make sure that the graph looks good, 
preferably by using the "gitk" tool to visualise.

cheers,
Derick

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

[Marco Pivetta]

I ended up voting NO due to the fact that there is no mention of `$this`
behavior changes ( https://externals.io/message/117888#117889 ) : I also
disagree with NikiC's stance on this being the same construct as before (
https://externals.io/message/117888#117897 ), so I really wanted to get rid
of this constant memleak risk that we have in closures. I should have made
my stance stronger, instead of letting the discussion thread die, but time
is what it is.

The idea is interesting, but I'd rather keep using the old construct until
the new one doesn't have the same pitfalls, and I'm fine with having to
type more characters for the time being.

The optimizations applied to the new proposal can probably be experimented
on short closures meanwhile (for PHP 9.0, since there will certainly be the
"edge of edgecases" somewhere), since there is hope for perf improvements
there too.

Unclear (to me) after looking at
https://gist.github.com/arnaud-lb/d9adfbf786ce9e37c7157b0f9c8d8e13, is
whether the optimizations are applied at compile time. It looks like the
changes are inside the `Zend/Optimizer/`, and `zend_compile.c`, so perhaps
the benchmarks are probably just worded in a confusing way.

Important to note how `Zend/zend_compile.c` now depends on `Optimizer/`,
which is a potential design issue.

Greets,

Marco Pivetta

https://twitter.com/Ocramius

https://ocramius.github.io/


On Fri, 1 Jul 2022 at 16:05, Larry Garfield  wrote:

> Greetings, Internalians.
>
> The vote for auto-capture closures is now open.  It will run until 15 July.
>
> https://wiki.php.net/rfc/auto-capture-closure
>
> --
>   Larry Garfield
>   la...@garfieldtech.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Vote] Auto-capture closures

[Nicolas Grekas]

Hi there,


Greetings, Internalians.
>
> The vote for auto-capture closures is now open.  It will run until 15 July.
>
> https://wiki.php.net/rfc/auto-capture-closure
>

Thanks for the RFC, I voted yes as I think the optimized auto-capturing
logic is sound.

Having "function()" still be a first-class citizen is also important to me
as there are cases where one might prefer the explicit nature of capturing,
so I join Rowan on this "rhetoric" topic.

I'm just wondering if there could be a way to enable the auto-capture
optimization for arrow functions. Having three kinds of rules for capturing
feels too much, especially when there are that subtles for short closures.
Maybe a deprecation could be possible for affected arrow functions?

Nicolas

[PHP-DEV] Re: PHP-8.1 branch seems broken

[Christoph M. Becker]

On 04.07.2022 at 10:16, Remi Collet wrote:

> In PHP 8.1:
>
> This branch is 1 commit ahead, 7 commits behind master.
>
>
> This seems terribly wrong, looks like was merged from master
> (NEWS file have 8.2 entries)
>
>
> Can some GIT expert check and fix that ?

Derick is working on fixing the issue.  Since he will need to reset to
the last good state, and force-push, everybody will have to fix their
clones afterwards (reset and pull).  Please do not push to any branch
until this is done.

Thanks,
Christoph

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP-8.1 branch seems broken

[Ilija Tovilo]

> > In PHP 8.1:
> >
> > This branch is 1 commit ahead, 7 commits behind master.
> >
> >
> > This seems terribly wrong, looks like was merged from master
> > (NEWS file have 8.2 entries)
> >
> >
> > Can some GIT expert check and fix that ?
>
> I guess that the "1 commit ahead" is just that your local branch is a merge
> with master.
> AFAICT, this has not been pushed.
>
> What about:
> $ git brand -D PHP-8.1
> $ git fetch
> $ git checkout PHP-8.1
>
> For a fresh start?

It looks broken on GitHub too. I think
ac6edbb73e701f6132b56065ff9343869feb4461 was accidentally pushed to
PHP-8.1 instead of master. PHP-8.1 should be reset to
110573726b6917580cd2c0c5d89c83e72f2de686.

I can try, but I'm not sure I have the permission to force-push.

Ilija

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP-8.1 branch seems broken

[Sebastian Bergmann]

Am 04.07.2022 um 11:04 schrieb Patrick ALLAERT:

I guess that the "1 commit ahead" is just that your local branch is a merge
with master.


No. If you look at https://github.com/php/php-src/tree/PHP-8.1 right now 
then you will see "This branch is 1 commit ahead, 7 commits behind master."


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP-8.1 branch seems broken

[Patrick ALLAERT]

Le lun. 4 juil. 2022 à 10:16, Remi Collet  a écrit :

> Hi,
>
> In PHP 8.1:
>
> This branch is 1 commit ahead, 7 commits behind master.
>
>
> This seems terribly wrong, looks like was merged from master
> (NEWS file have 8.2 entries)
>
>
> Can some GIT expert check and fix that ?
>
>
> Regards,
> Remi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Hi Remi,

I guess that the "1 commit ahead" is just that your local branch is a merge
with master.
AFAICT, this has not been pushed.

What about:
$ git brand -D PHP-8.1
$ git fetch
$ git checkout PHP-8.1

For a fresh start?

-- 
-Patrick

[PHP-DEV] PHP-8.1 branch seems broken

[Remi Collet]

Hi,

In PHP 8.1:

This branch is 1 commit ahead, 7 commits behind master.


This seems terribly wrong, looks like was merged from master
(NEWS file have 8.2 entries)


Can some GIT expert check and fix that ?


Regards,
Remi

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Tim Düsterhus]

Hi

On 7/4/22 09:38, Timon de Groot wrote:

If the rest also thinks the RFC is good to go, I suggest we start a vote
coming week.


With the minimum voting period being 14 days as per 
https://wiki.php.net/RFC/voting#voting and the feature freeze for PHP 
8.2 being 2022-07-19 23:59:59 UTC as per 
https://externals.io/message/118025#118028, starting the vote in the 
coming week is too late. The vote needs to start no later than July, 5th 
23:59 UTC (i.e. tomorrow).


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Timon de Groot]

As a flag can't really hurt, I'm thinking of going with option B before 
starting the vote.
Also agree with ignoring the indent parameter, as a tab character is 
less dependent on how much it is repeated.


Kind regards,

Timon

On 04-07-2022 03:22, Kevin Israel wrote:

On 7/3/22 18:01, Jakub Zelenka wrote:
  I think we can put this RFC to the vote. If the author is to busy I 
would
like to start voting later this week. It would be a pity not to make 
it to
feature freeze as it is quite straight forward and the implementation 
seems

good as well so I guess we don't need to wait extra year. :)

Cheers

Jakub

This RFC really should have included an option to use tabs instead of 
spaces, which is, IMO, even more important than having a parameter for 
the number of spaces. This could take the form of either


(a) a magic indent value such as -1, or

(b) a new flag (suggested name: JSON_INDENT_USING_TABS).

There should be no need to support indenting using multiple tabs per 
level; for option (b), the value of the indent parameter should be ignored.


An indent-using-tabs flag would even be useful for generating two-space 
indented JSON, should the proposed indent parameter be rejected. The 
reason is that tabs cannot occur within JSON string representations, so 
any other indent string is a simple str_replace() away. In contrast, 
replacing the current four-space indent with anything else is more 
complicated to do efficiently[1].


[1]: 
https://github.com/wikimedia/mediawiki/blob/210a34369ac8f0ba74b497d0b2298ca7e5a0bffb/includes/json/FormatJson.php#L113-L117 





--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Add json_encode indent parameter

[Timon de Groot]

Hi internals,

If the rest also thinks the RFC is good to go, I suggest we start a vote 
coming week.
As this is my first RFC, I'm not so sure how this typically gets kicked 
off, so I'd like to know what I need to do!


Kind regards,

Timon

On 04-07-2022 00:01, Jakub Zelenka wrote:

Hi,

On Fri, May 13, 2022 at 2:33 PM Timon de Groot > wrote:


Hi internals,

Almost a year ago I first proposed my RFC draft to introduce a new
json_encode parameter 'indent'. I have received a lot of feedback on
the
change, very insightful. The feedback can be boiled down to:
- Accepting user input characters means you could create invalid JSON.
    Do we want that? Should it be complying with the spec[1]?
- Preference for pure types, so int OR string, not both.

So I think I made the change more complex than it should have been and
considered the three options:
    1) Accept indent as an int, which will result in N spaces of indent
per indentation level.
    2) Accept indent as a string, which will result in string N per
indentation level.
    3) Accept indent as an int and indent_char as string, which will
result in N * indent_char per indentation level.

Option 1 seems very simple and feasible while not being confusing.
Option 2 seems feasible, but somewhat more complex, because user input
should be validated.
Option 3 seems very flexible, but in my opinion very confusing at the
same time, while I'm not sure there's even a use case for this level of
flexibility.

I have updated the pull request[2] and RFC[3] to be based on option 1,
as I think this offers clear functionality and I feel like I can't
really go wrong with the indent parameter as an int.

Please let me know what your thoughts are and what needs to be done to
get this RFC going forward!


  I think we can put this RFC to the vote. If the author is to busy I 
would like to start voting later this week. It would be a pity not to 
make it to feature freeze as it is quite straight forward and the 
implementation seems good as well so I guess we don't need to wait extra 
year. :)


Cheers

Jakub


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Make the iterator_*() family accept all iterables

[Tim Düsterhus , WoltLab GmbH]

Hi

On 6/21/22 16:27, Tim Düsterhus, WoltLab GmbH wrote:

https://wiki.php.net/rfc/iterator_xyz_accept_array

which I am officially opening up for discussion, just in time for PHP 8.2.

Voting will start in 2 weeks on 2022-07-05. Voting will end in 4 weeks
on 2022-07-19.


Tomorrow is the 5th, here's the voting start heads-up :-)

Best regards
Tim Düsterhus
Developer WoltLab GmbH

--

WoltLab GmbH
Nedlitzer Str. 27B
14469 Potsdam

Tel.: +49 331 96784338

duester...@woltlab.com
www.woltlab.com

Managing director:
Marcel Werk

AG Potsdam HRB 26795 P

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php