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

[Will Fitch]

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
>> available.
>> 
> 
> 
> Correct, usually we disable issues and point users to bugs.php.net to
> have a central bug database instead of having to track multiple
> trackers. Usually repos are created via a script on https://master.php.
> net/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 destroy history)
> 
> Will, I made you collaborator on the repo, so you can respond to the
> ticket properly and close it or whatever. A bit later I'll turn issues
> of. Please be careful not to directly push to the repo.
> 
> johannes
> 
> 

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

[PHP-DEV] GitHub and Extensions

[Will Fitch]

Hi All -

What is the process of closing out pull requests on GitHub for extensions
we maintain? For example:
https://github.com/php/pecl-numbers-bitset/issues/11 - I have no way of
closing that out other than to push a bogus commit with "Fix #11" as the
message.

Is there are grant option for GitHub extension maintainers? If so, both PHP
and GH username is willfitch.

Thanks,

Will Fitch

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

[Will Fitch]

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 feedback on this RFC, with a
> few areas especially:
> 
> 1. How scared are we that integers can be expanded to floats on runtime?

First, this looks awesome, Phil!  

After reading through it, I think we can consult with function return
types:

function blah() : int {
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 instead error
> after the constructor has been called if they are still not holding a
> value?
> 
> 3. Weak vs Strict. Right now this is entirely strict, with no
> declare() to change mode. Reasons for this vary, from various sources,
> but include "Not sure how to implement it" and "Well people should not
> be using properties as part of their public API".
> 
> Help on 3 would be appreciated.
> 
> Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
> rather common rhetoric. Strict Type Hinting might have been seen as a
> battleground for fans of strict and fans of weak to fight through a
> keyboard, but this RFC will not be the repeat.
> 
> We'll have a nice, orderly, constructive conversation about this RFC,
> and improve the patch as you all provide feedback.
> 
> Let me know what you think folks!
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php

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

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

[Will Fitch]

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,
> >>>
> >>> I've opened the vote on https://wiki.php.net/rfc/mcrypt-viking-funeral
> >>> which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
> >>> (i.e.
> >>> 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 better.
> >>>
> >>> This vote is opened on March 15th, 2016 and will close March 22th at
> >>> 17:00
> >>> UTC.
> >>>
> >>> (Sidenote: Apologies for the brief unannounced hiatus from participating
> >>> here.)
> >>>
> >>> Scott Arciszewski
> >>> Chief Development Officer
> >>> Paragon Initiative Enterprises 
> >>>

In the RFC:

"Removal from core: The following major/minor version (7.2.0 or 8.0.0)"

and then

"Vote “Yes” to raise an E_DEPRECATED notice in PHP 7.1 when any mcrypt
function is used and to remove the extension from core in 7.1+1."

Which one is it? I feel removing at 7.2 would be too soon.  I agree that
the abandonware is a nuisance, but many developers using ext/mcrypt have
no idea of this.  Raising an E_DEPRECATED in the next 7.1.x, then
removing in 7.2 is just too soon.  


> >>
> >> hi,
> >>
> >> first some formalities:
> >> please make sure to follow the process stated at
> >> https://wiki.php.net/rfc/voting
> >> New RFCs first should be proposed for discussion and it would require a
> >> bit of vetting before it can be moved to the voting phase.
> >> I can see your thread "mcrypt extermination plan" but I can't find any
> >> mail linking to the rfc page before this one instantly moving it into
> >> voting phase.
> >> I would suggest cancelling the vote and waiting a bit(I would say 2
> >> weeks) for any discussion/feedback on the rfc itself.
> >> Personally I also don't like going with the minimal one week voting
> >> period as it is too easy for somebody to miss the chance to vote because of
> >> vacation or just a busy week.
> >> ​​
> >>
> >> I also wanted to mention that some of unsupported ciphers listed under
> >> https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
> >> can in fact be supported by openssl as it(openssl) allows the usage of
> >> plugable engines.
> >> --
> >> Ferenc Kovács
> >> @Tyr43l - http://tyrael.hu
> >>
> >
> >
> >
> > https://wiki.php.net/rfc/mcrypt-viking-funeral?do=revisions <- already
> > been under discussion for a while
> >
> > ​> ​I also wanted to mention that some of unsupported ciphers listed
> > under
> > https://wiki.php.net/rfc/mcrypt-viking-funeral#backward_incompatible_changes
> >  can in fact be supported by openssl as it(openssl) allows the usage of
> > plugable engines.
> >
> > Can be supported !== is currently supported out of the box.
> >
> > Scott Arciszewski
> > Chief Development Officer
> > Paragon Initiative Enterprises 
> > ​
> >
> >
> sure, but I still think that it would worth mentioning the possibility
> instead of stating that there is no migration path available for those
> ciphers.
> 
> -- 
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu

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

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

[Will Fitch]

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) extensions involved isn't playing nice with PHP7, which I'll
> look into separately.
If you haven't already done so, please file a bug report.  The files
uploaded aren't very helpful in terms of diagnosing the issue.
>
> ZIP of the INI files is here:
> https://drive.google.com/file/d/0B6sRKna1qL1IamxmN3lOT3Y2WDA/view?usp=sharing
 

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

[Will Fitch]

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=0xd314c15417d73c46)
> at Zend/zend_ini_scanner.c:3724
> #1  0x0067da19 in init_executor ()
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_execute_API.c:176
> #2  0x00669862 in zend_string_alloc (persistent=0,
> len=140720308486145)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_string.h:134
> #3  zend_string_init (persistent=0, len=18446744069414584336, str=0x0)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_string.h:157
> #4  zend_compile_dynamic_call (result=0x7f2afa13e8a0,
> name_node=0x7f020040, args_ast=0x67da19 )
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:2867
> #5  0x00671e99 in zend_compile_class_decl (ast=0x7f2afa389910)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:5262
> #6  0x006678ad in zend_compile_dim (result=0x7f2afa154268,
> ast=0x7f2afa154268, type=32554)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:2301
> #7  0x00671d62 in zend_compile_class_decl (ast=0x7f2afa1f77c0)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:5242
> #8  0x0066b307 in zend_ast_get_list (ast=0x7f2af9eaf7e0)
> at /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_ast.h:221
> #9  zend_compile_call (result=0x7f2af9e527e0, ast=0x7ffc412f7f50,
> type=32554)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:3236
> #10 0x00671eda in zend_compile_class_decl (ast=0x7f2af9ea2a50)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:5262
> #11 0x00671b11 in zend_compile_class_decl (ast=0x12de10)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:5208
> #12 0x00671af3 in zend_string_release (s=0x0)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_string.h:271
> #13 zend_compile_class_decl (ast=0x7f2b4e7ced50)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:5207
> #14 0x00629310 in zendparse ()
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_language_parser.c:4357
> #15 0x0067666e in zend_string_alloc (persistent=32554, len=32768)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_string.h:121
> #16 zend_string_init (persistent=32764, len=0,
> str=0x10005d1a00 )
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_string.h:157
> #17 zend_compile_shell_exec (result=0x0, ast=0x0)
> at
> /wayfair/home/cmccoy/rpmbuild/BUILD/php-7.0.3/Zend/zend_compile.c:6438
> #18 0x7f2b47e8e202 in ?? ()
> #19 0x7ffc412f92f8 in ?? ()
> #20 0x in ?? ()
> 
> I found this bug which sounds a little similar, though it appears to have
> been fixed:
> https://bugs.php.net/bug.php?id=70748
> 
> Does anyone have any suggestions for how to debug?
> 
> Thanks,
> Adam

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

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Nov 7, 2014, at 12:16 AM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 On Thu, Nov 6, 2014 at 7:56 PM, Andrea Faulds a...@ajf.me 
 mailto:a...@ajf.me wrote:
 
 
 On 7 Nov 2014, at 00:53, Stas Malyshev smalys...@sugarcrm.com 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.
 
 Sure, PHP could easily do this, or any other one specific use case for
 you. What it can't do, however, is to do all 1000 use cases that modern
 REST application presents, automatically for you. What if you use XML
 and not JSON? What if you use both and determine which one it is by
 request URL suffix being .xml or .json? What if it instead is switched
 by query parameter? What if also it can be compressed, encrypted and
 wrapped in some MIME multipart message? Having all these complications
 handled in the core of PHP would be extremely hard, not because each of
 them is hard, but because there can be so many of them. And you'd run a
 big change of PHP still not matching your specific case exactly, or
 being behind times, because core can not evolve as quickly as userland
 does. That's why it's better done in extensions or user space - unless
 you can identify a case which covers a huge proportion of all cases -
 just like forms are for POST. For generic REST, I'm not sure there's
 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 parse JSON (objects
 vs. arrays, big numbers as floats or strings, etc.), while for form-data
 there’s only one way.
 
 
 Well, in this case it will be parsed as an array since $_POST is naturally
 parsed as an array. Also, since $_POST/$_GET are typically always processed
 as strings it would only make sense to use big numbers as strings in the
 JSON parsing as well. I don't think this is the big issue. The bigger issue
 is do users typically find the population of $_POST more useful than just
 reading the input stream themselves and handling the JSON payload on their
 own.

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 
responsive action is to argue back.  Why aren’t you considering alternatives?  
Everything - and I do mean everything - that you want is available in 
pecl/http, and there’s already an RFC to get it into core.  Why can’t you get 
behind that and either support it, or move to propose an alternative that is 
supportable by at least someone.  Your current proposal is not supported by 
anyone in this thread, and you still can’t see that.

I admire and appreciate your efforts in making PHP better, but it’s time to go 
back to the drawing board on this proposal.  Everyone is against it, and I feel 
this thread’s patience is running thin.

 
 
 
 --
 Andrea Faulds
 http://ajf.me/ http://ajf.me/

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Nov 7, 2014, at 12:38 AM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 
 
 On Fri, Nov 7, 2014 at 12:23 AM, Will Fitch willfi...@php.net 
 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.  You continue to try and make this case, but 
 it continues to be shot down with absolutely valid issues, and your only 
 responsive action is to argue back.  Why aren’t you considering alternatives? 
  Everything - and I do mean everything - that you want is available in 
 pecl/http, and there’s already an RFC to get it into core.  Why can’t you get 
 behind that and either support it, or move to propose an alternative that is 
 supportable by at least someone.  Your current proposal is not supported by 
 anyone in this thread, and you still can’t see that.
 
 I admire and appreciate your efforts in making PHP better, but it’s time to 
 go back to the drawing board on this proposal.  Everyone is against it, and I 
 feel this thread’s patience is running thin.
 
 
 I think you're looking too closely at the problem to have an objective view. 
 While I appreciate your continued input and feedback, I don't believe you're 
 fairly judging my motives or my objectives. Who says I'm not considering 
 alternatives? You have to keep in mind the RFC is still in draft. I'm 
 technically not even putting up for discussion yet because I've failed to 
 make a coherent proposal. I get that. I'd still like to hear what others have 
 to say. I will make my own assessments of the collective facts. In the mean 
 time I'm OK with the discussion of my initial proposal being objectionable. I 
 gladly embrace failure as I expect to learn from it.

It’s only a failure if you don’t learn from it and stop. I admire your efforts.

 
 I'm not sure why it is you feel as though me having a technical discussion 
 with the community equates to me agreeing with everyone else's opinion or 
 ending a discussion on the note that it is no longer useful because everyone 
 disagrees with me.

The discussion would be more useful if you proposed an alternative.  So far, 
all I’ve seen is arguments why your original discussion could work.

 
 I gather valuable knowledge from disagreement and intend to pursue those 
 disagreements until I can reach a fully objective outlook on all of the 
 moving parts at hand. I don't wish to abandon this discussion because the 
 initial proposal has no support.

Nor should you. I do feel that time has been reached as there are multiple 
people that have retired from discussing this further. That is an indicator 
that this discussion has run its course.

 
 I'm sorry if you feel that you are no longer interested in the discussion, 
 but can you at least refrain from cluttering the discussion aggressively with 
 your synopsis? Everyone is providing valuable objective outlooks and those 
 that have no more objectivity have seemingly refrained from further 
 discussion. That I'm perfectly OK with. What I'm not OK with is someone that 
 feels they must terminate the discussion because there is disagreement. I am 
 in the very process of understanding others' disagreements. Please do not 
 impede on my efforts by assuming you have any idea what is going on in my 
 head.

I am very interested in discussing this - but not in discussing the same 
proposal over and over.  We have beaten a dead horse, and the horse has come 
back as a zombie and been defeated twice over.  I actually believe your point 
is valid that the HTTP interface could use some work, but the approach you’re 
pushing just isn’t it.

 
 Thanks.

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Nov 5, 2014, at 9:23 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 On Wed, Nov 5, 2014 at 8:38 PM, Andrea Faulds a...@ajf.me wrote:
 
 
 On 6 Nov 2014, at 01:29, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 So you're actually describing two semi-different problems here. One is
 that PHP doesn't actually inform you of the HTTP request VERB strictly
 through the naming of the super global variables $_POST and $_GET. However,
 $_POST being populated, right now, in PHP, strictly means the request verb
 was POST and that the content-type header received was multipart form data.
 Which means that sending something like a JSON payload (Content-type
 application/x-json or whatever) in the body of a POST request still doesn't
 populate the $_POST super global variable even though the HTTP request VERB
 was indeed POST.
 
 That’s not actually my complaint. The thing is that, until now, you could
 assume what was in $_POST was from a POST request. To allow data from PUT
 and DELETE requests to go there by default is probably not a good idea,
 because POST has quite a different meaning from PUT and DELETE.
 
 
 Sure, $_POST has become synonymous with form data. I get that. I have no
 idea why you think populating it with data from other request types,
 however, would necessarily be a bad idea. If the request verb changes but
 the request contains a multipart mime, I see no reason not to populate it
 other than its name becoming more alluding. The meaning of PUT or DELETE is
 irrelevant here because all we're discussing is parsing the form data part
 of the multipart request (regardless of it's HTTP request VERB). So the
 meaning of the request verb isn't a justification for what to name the
 super global variable that gets populated either. The super global was
 intended for form data and I'm not changing that intention when allowing it
 to get populated by additional request verbs.

Easy - you have no idea what the input type is from PUT without checking the 
incoming type.  With POST, you know exactly what it is. PUT input code be JSON, 
multipart mime, a file or a whatever the dev wants.

 
 
 
 The other problem is that the semantics of REST itself are quite
 different from how PHP currently deals with the request data. In that PHP
 only cares about form data. However, this is quite antiquated with todays'
 modern use of HTTP growing in API-specific functionality. For example,
 companies like Twitter and Tumblr, demonstrate a vast majority of their
 traffic currently coming in at the API-level where things are usually
 handled in a RESTful manner. So for the PHP power houses today, PHP doesn't
 quite lend itself well to dealing with these problems first-hand. Instead
 we have to hack our way around them in userland, which can be more
 error-prone and less obvious.
 
 Er… I wouldn’t say that PHP really handles REST APIs badly, or that the
 userland approach is error-prone or less obvious. Using JSON isn’t
 difficult, you just do this:
 
$data = json_decode(file_get_contents(‘php://input')) or die();
 
 This isn’t a hack. It’s a straightforward and obvious way to do this.
 
 
 
 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.
 Further more, you ignore all the other aspects of parsing the request body
 like when the PUT payload is a multipart mime, with both form data and a
 base64 encoded binary part or several of them. Again, PHP could just as
 easily take care of this in the same way it does now with POST and populate
 $_FILES and other form data accordingly.

You’re suggesting we change the fundamental approach of PHP in terms of what 
these superglobals represent.  I think from the feedback on this list, the 
approach you’re suggesting is far from welcome. Perhaps this is something you 
should stop arguing and start looking at improving your RFC with something 
that’s different and potentially acceptable.

 
 
 
 
 While that solution solves one specific problem (dealing with multipart
 form data of request types other than POST), it doesn't quite tackle some
 of the broader issues of dealing with incoming HTTP request in PHP that I
 would like to tackle.
 
 Yes, I’m aware it doesn’t. I don’t think that the PUT/DELETE issue really
 justifies your RFC. I don’t think there are any other problems which do,
 either. There are better ways to solve them.
 
 
 Well, the RFC is intended to tackle the current issues of dealing with the
 HTTP request where PHP now fails. Everything outside of form data and
 multipart requests specifically using POST fall under that umbrella. So I'm
 not sure why you think this RFC isn't justified.
 
 What are these better ways? Please, do elaborate. I'm more than open to a
 better solution even if that entails heading down a different path. I just
 don't think that a response of this RFC 

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Nov 5, 2014, at 10:00 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 
 
 On Wed, Nov 5, 2014 at 9:36 PM, Will Fitch willfi...@php.net 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 is. PUT input code be 
 JSON, multipart mime, a file or a whatever the dev wants.
 
 
 That's not necessarily true. There are many APIs that will send POST requests 
 with a JSON payload in the request body. This is specifically why PHP won't 
 bother parsing the request entity body unless the content-type header is form 
 ulr-encoded. Additionally you have to take Content-encoding[1] into 
 consideration as HTTP doesn't require that the body of a POST request be 
 url-encoded, just that the client specifies the content-encoding and 
 content-type[2][3] for entity decoding and then it becomes up to the server 
 how to handle or even accept the entity.

I think a simple quote from RFC 2616 is necessary:

The fundamental difference between the POST and PUT requests is reflected in 
the different meaning of the Request-URI. The URI in a POST request identifies 
the resource that will handle the enclosed entity. That resource might be a 
data-accepting process, a gateway to some other protocol, or a separate entity 
that accepts annotations. In contrast, the URI in a PUT request identifies the 
entity enclosed with the request -- the user agent knows what URI is intended 
and the server MUST NOT attempt to apply the request to some other resource. If 
the server desires that the request be applied to a different URI,
it MUST send a 301 (Moved Permanently) response; the user agent MAY then make 
its own decision regarding whether or not to redirect the request.

(http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html)

There is nothing relevant to data transformation between PUT and POST. It is, 
for all intents and purposes, two completely different methods and you should 
not assume one is similar to the other - especially based solely on what you 
want PUT to do. PUT can contain query strings, POST-like bodies and files or a 
combination of any.  

Bottom line - you’re trying to change PHP’s form handling approach with your 
view of what PUT could/should be doing.  Don’t do that.

It’s blowing my mind that you are still arguing this point, and I believe it’s 
time to put it to bed.  Come up with a better solution, put this RFC to a vote 
(even without a patch) or retract it.  You have have almost nothing but 
criticism, and this thread is at the point of wasting valuable time.


 
 [1] http://tools.ietf.org/html/rfc2616#section-14.11
 [2] http://tools.ietf.org/html/rfc2616#section-14.17
 [3] http://tools.ietf.org/html/rfc2616#section-7.2.1
  
 
 You’re suggesting we change the fundamental approach of PHP in terms of what 
 these superglobals represent.
 
 
 Not at all, $_GET and $_POST in PHP have always represented form data. I wish 
 to keep that intact. This approach merely amends under which HTTP verbs form 
 data can be accepted and the potential to accept media types other than 
 form/url-encoded. If the latter part deviates too much from the concept of 
 form data (it likely does) then that can become a separate vote in the RFC.
  
 I think from the feedback on this list, the approach you’re suggesting is far 
 from welcome. Perhaps this is something you should stop arguing and start 
 looking at improving your RFC with something that’s different and potentially 
 acceptable.
 
 
  
 Improving the RFC is precisely what I'm looking to do :)
 
 Surely the only way to find out what is or is not acceptable is to poll 
 others get some form of popular consensus. Perhaps you should take the 
 discussion as less of a battle and more of an opportunity to voice individual 
 objectivity? I have no intention of being hostile. I'm also more than open to 
 the possibility that this RFC may not be favored, but that doesn't negate the 
 effort to build a more favorable RFC based on this discussion.
 
 


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

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

[Will Fitch]

 On Oct 31, 2014, at 12:10 PM, Andrea Faulds a...@ajf.me wrote:
 
 
 On 30 Oct 2014, at 21:57, John Bafford jbaff...@zort.net 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 volunteering to lead such a team, should the RFC be 
 approved.
 
 https://wiki.php.net/rfc/github-pr
 
 PHP’s GitHub repository has over 180 open pull requests. Many of these are 
 bug fixes or new tests that should be incorporated into PHP, but have not 
 been because the PRs aren’t being regularly monitored. As a result, the 
 large number of open pull requests may also be discouraging contributions, 
 as potential contributors may see that pull requests are not being acted on 
 and decline to submit changes.
 
 Glad to see this, the pull request situation is really getting out of hand.

Ditto on this as well. We also need a better way of managing other PHP 
repository (e.g. PECL extensions) PRs.  I was just talking to Rasmus, Hannes 
and Ferenc about this today, and it appears the https://qa.php.net/pulls 
https://qa.php.net/pulls has been down for some time.  

 
 I’d like to make a small request, though. For RFCs, there should be a 
 distinction between RFCs that haven’t yet passed, which have pull requests 
 mainly for code review purposes, and RFCs that have passed, which are waiting 
 to be merged. Actually, it might be best to generally ignore RFC pull 
 requests. For those that haven’t yet passed, they just want someone to look 
 at the code. For those that have, if the author has commit access, they don’t 
 need 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] New Standardized HTTP Interface

[Will Fitch]

 On Oct 31, 2014, at 4:05 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 On Fri, Oct 31, 2014 at 3:35 PM, Rowan Collins rowan.coll...@gmail.com
 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 related to
 this RFC.
 
 
 The decision about *whether this is needed in core* is not something you
 can ignore by saying this is about core. The fact that PHP-FIG is working
 on something very closely related to this makes a difference to that
 question, and pretending that's irrelevant is not constructive.
 
 
 First of all, I'm not ignoring anything. I very much appreciate all of your
 input. However, reiterating what you've already 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, reiterating the pecl/http approach is 
indirectly what your asking for? I have mentioned this numerous times, but you 
haven’t responded with a reason not to take this approach - which is an RFC 
that was presented for discussion prior to yours.  Forgetting about FIG or PSR, 
if pecl/http v2 made it into core/ext, would this not satisfy your concerns 
described in your RFC and conversations?

We’re spinning wheels here, and so many, mostly core developers, have been 
reiterating the resistance to superglobals, and rightfully so.  I would suggest 
either concentrating the efforts you’re trying here towards existing efforts 
(pecl/http), or present a better approach.

 
 I read what you've had to say about FIG and PSR and I'm taking it into
 consideration. That doesn't mean I have to yield to your preference. Nor
 does that mean this RFC has now become irrelevant because somewhere on
 planet earth someone has come up with a competing idea/concept. I welcome
 competition. That is only beneficial to PHP.
 
 If you would like to further this discussion beyond reiterating the words
 PSR and FIG then please explain to me how what you're talking about solves
 any of the problems I'm attempting to solve with this RFC? Namely, how does
 this PSR solve the problem that PHP will not populate $_FILES or $_POST if
 a multipart PUT request is sent to PHP? Pointing out specifics, using
 references, and providing any additional examples/documentation is more
 than welcome if it will help me improve this RFC (but only if it is geared
 toward the same goals that this RFC has).
 
 Thanks


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

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Oct 31, 2014, at 4:21 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 
 
 On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch willfi...@php.net 
 mailto:willfi...@php.net wrote:
 
 
 
 While not too specific to Rowan, reiterating the pecl/http approach is 
 indirectly what your asking for? I have mentioned this numerous times, but 
 you haven’t responded with a reason not to take this approach - which is an 
 RFC that was presented for discussion prior to yours.  
 
 I'm trying to understand how pecl/http solves the aforementioned problem any 
 better? Again, I have no problem with competing ideas and it's not as though 
 one is prohibited from presenting an idea for the mere fact that there exists 
 a competing one. I'm just not seeing how pecl/http solves the problem I 
 intend to solve better. The reason I haven't responded to you yet is because 
 I'm stilling weighing the two to try and make sense of whether or not these 
 are in fact competing ideas or complimenting ones.
 
 Please, feel free to weigh in with anything that contradicts or concludes 
 what I'm saying. I certainly don't expect to have all of the answers.

What doesn’t pecl/http solve under your situation? The fact that’s it’s not 
directly integrated as part of ZE and handling process? 

I certainly have no problem with competing ideas either. However, the only 
proposed patch in this RFC is a gist with PHP pseudocode.  

  
 

[PHP-DEV] pecl/http RFC

[Will Fitch]

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 
https://wiki.php.net/rfc/pecl_http.  

Recent conversations regarding https://wiki.php.net/rfc/http-interface 
https://wiki.php.net/rfc/http-interface make this approach far more realistic 
and approachable.  I think discussions regarding the two should be hashed, and 
one or the other come out on top.  They have competing aspects, but pecl/http 
has a proven and well-known interface.  It’s high-time, at the very least, that 
it be considered for core.

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Oct 31, 2014, at 4:51 PM, Sherif Ramadan theanomaly...@gmail.com wrote:
 
 On Fri, Oct 31, 2014 at 4:29 PM, Will Fitch willfi...@php.net wrote:
 
 
 On Oct 31, 2014, at 4:21 PM, Sherif Ramadan theanomaly...@gmail.com
 wrote:
 
 
 
 On Fri, Oct 31, 2014 at 4:16 PM, Will Fitch willfi...@php.net wrote:
 
 
 
 
 While not too specific to Rowan, reiterating the pecl/http approach is
 indirectly what your asking for? I have mentioned this numerous times, but
 you haven’t responded with a reason not to take this approach - which is an
 RFC that was presented for discussion prior to yours.
 
 
 I'm trying to understand how pecl/http solves the aforementioned problem
 any better? Again, I have no problem with competing ideas and it's not as
 though one is prohibited from presenting an idea for the mere fact that
 there exists a competing one. I'm just not seeing how pecl/http solves the
 problem I intend to solve better. The reason I haven't responded to you yet
 is because I'm stilling weighing the two to try and make sense of whether
 or not these are in fact competing ideas or complimenting ones.
 
 Please, feel free to weigh in with anything that contradicts or concludes
 what I'm saying. I certainly don't expect to have all of the answers.
 
 
 What doesn’t pecl/http solve under your situation? The fact that’s it’s
 not directly integrated as part of ZE and handling process?
 
 
 
 Well, you're the one suggesting an alternative. The onus is on you to prove
 that it solves the same problem, not me. However, I'll bite for the
 purposes of moving the discussion along…

I’m actually not suggesting an alternative - I’m suggesting this RFC isn’t an 
option.

 
 As far as I understand, pecl/http attempts to solve a much larger scope of
 problems than this RFC. Namely, dealing with HTTP messages in general,
 whether they are a part of PHP's request/response model or not. i.e. there
 is no direct integration of the PHP request into pecl/http and as such it
 doesn't directly solve a problem such as properly parsing the HTTP request
 body during a PUT request and properly populating the $_FILES/$_POST
 superglobals. It also doesn't solve similar problems where a transport
 message body is sent entirely in JSON to PHP and PHP is responsible for
 handling.

Sure, pecl/http solves a much larger scope of problems related to HTTP, but 
that does not mean it can’t serve the purpose you’re trying to accomplish.  If 
your attempt is to force everyone into an approach using the defined 
interfaces/classes in the RFC, this is going nowhere.  First of all, you’re 
assuming PHP is an OOP-only language.  

 
 Of course, yes, you can do accomplish this today with some hacks like using
 the php://input stream, but it's only up until recently that this stream
 has become reusable. It's also potentially creating some duplication, but
 albeit this isn't the only problem.

You don’t need to tie into the input stream - use pecl/http...

 
 This RFC also attempts to make it possible for users to directly apply
 filters to input from the HTTP request so that they can simply retrieve the
 fitlered data from the HttpRequest object directly without having to do
 things like $foo = isset($_POST['foo']) ? filter_var($_POST['foo'],
 FILTER_VAR_INT) : 0; // for example

I understand why you’d want this in specific use-cases, but don’t tie everyone 
to your needs. This isn’t a requirement for a language.  Plenty of frameworks 
can provide exactly what you’re describing.

 
 I have nothing against pecl/http. I think it's a very useful library and
 Mike seems to have put a great deal of work into it. I would gladly vote it
 into PHP core. I'm just not clear on how it solves the same problems this
 RFC attempts to solve. They can actually compliment each other in some
 areas; I can see that.
 
 
 
 
 I certainly have no problem with competing ideas either. However, the only
 proposed patch in this RFC is a gist with PHP pseudocode.
 
 
 
 
 
 It's not pseudocode since it's actually perfectly valid PHP code that will
 compile and run in the PHP interpreter. However, it is intended to
 demonstrate the behavior. The pecl/http RFC is also further along as it's
 in discussion phase with an actual implementation. This RFC is merely a
 draft, with no actual implementation proposed yet (but that's not at all
 uncommon as many RFCs proposed in PHP did not provide an actual
 implementation until after they were voted in: generators, list in foreach,
 and finally are among a small number that come to mind). So let's not get
 hung up on implementation being the barrier to entry for an RFC as that's
 never ever been the case in the past.

My apologies.  Please replace pseudocode with prototypes.

 
 It is, however, entirely understandable that the RFC should explain the
 actual behavior and consequences as well as possible if it does not provide
 an actual implementation. This is just a very early stage discussion to
 gather ideas so that I can improve

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

[Will Fitch]

 On Oct 30, 2014, at 2:13 AM, Christian Stoller stol...@leonex.de 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 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 quickly created/destroyed, so hashes can
 be the same for several different objects. However, will it be better to
 introduce an interface for that? For example, Hashable can be a good name
 (like Traversable one). Default implementation then can be a simple trait
 that will be added later to the concrete class.
 
 
 I like the idea introducing an interface for this functionality, instead
 of adding a further magic method. But I think anything like hash or
 hashable is confusing for users.

The magic method is more of a PHP approach while an interface would be more 
appropriate.  That said, this RFC is a true representation of a hash vs 
something like spl_object_hash.  That’s what causes user confusion.  
spl_object_hash would’ve been better served as a name like spl_object_id or 
spl_object_hash_id.  Something that indicates uniqueness regardless of the 
values of a particular object.

 
 Maybe something like 
 
 interface ArrayKeyConvertable
 {
function toArrayKey();
 }
 
 
 Christian


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

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

[Will Fitch]

 On Oct 30, 2014, at 1:32 PM, Stas Malyshev smalys...@sugarcrm.com 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 $arr now contain one value or two?
 
 That depends on the semantics of class Foo. If Foo is something like
 UString, then it should contain one value, since UString is a value
 object (https://en.wikipedia.org/wiki/Value_object) - or at least it
 should be. However, if Foo represents something having separate identity
 - i.e. it's a Person class and 'bar' represents name - then of course it
 should contain two values, since the name is not the sole source of
 Person's identity. So the decision is on you as a programmer.
 
 And to give you the tool to make this decision and let PHP engine know
 about is exactly the point of this RFC.

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 must be 
unique to each object. 

Any thoughts on that?

 
 If the desire is for it to contain 2, then spl_object_hash($a) already 
 has that covered, I think.
 
 If the desire is for it to contain 1, then the proposal sounds like a 
 way to normalize Foo::stringifiedValueObjectEquivalent().
 
 You can describe it as such, but in a proper standartized way and with
 syntax that allows you to use same syntax constructs on all keys and not
 have to check each time if it's a special value and call a special
 function on it (same purpose as for __toString).
 -- 
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

Re: [PHP-DEV] New Standardized HTTP Interface

[Will Fitch]

 On Oct 30, 2014, at 4:15 PM, Andrea Faulds a...@ajf.me wrote:
 
 
 On 30 Oct 2014, at 20:49, Sherif Ramadan theanomaly...@gmail.com 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 HttpRequest class, for example, which the user can then 
 extend to override default behavior or modify it as they see fit for their 
 particular use case. This is much like the Session interface, which makes it 
 possible to change session storage mechanisms in userland, but still have a 
 confirming method of session handling in PHP.
 
 You know, before I keep up this discussion, it’d be nice if you clarified 
 what, exactly, you are proposing. The RFC contains no detail at all. I really 
 haven’t 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. :(
 
 So the fix to something like PUT/DELETE requests is to add yet another super 
 global.
 
 No, not really. $_PUT and $_DELETE don’t really make sense, why are you 
 sending form data to PUT or DELETE? Populating $_POST also makes sense, it’s 
 not a POST request. The answer is just to add a function to do multipart 
 parsing, to expose PHP’s current parser, which satisfies the obscure use case 
 of needing form data parsing for PUT and DELETE. I don’t think this would be 
 too hard to do.

It's not hard. Again, pecl/http v2 proposal will give core everything it needs. 
I honestly don't know why this is being discussed any further when theirs a 
solution that gives functionality requested here and contains zero BC breaks. 

 --
 Andrea Faulds
 http://ajf.me/
 
 
 
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

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

[Will Fitch]

 On Oct 30, 2014, at 3:28 PM, Andrea Faulds a...@ajf.me wrote:
 
 
 On 30 Oct 2014, at 19:51, Will Fitch willfi...@fastmail.fm 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 must 
 be unique to each object.
 
 In addition to what Stas says above, well, not all objects work like that. 
 What if I want objects to hash by value, not by identity? Don’t force the 
 identity model.

I’m not suggesting we force anything.  The tone of the conversation earlier 
referred to using spl_object_hash as a default.  If we don’t do this, that’s 
totally fine.

We don’t have an “__equals” equivalent to Java’s equals().  While I understand 
the intent of this RFC is not to address that, perhaps it should be considered 
in the future.


 --
 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

[Will Fitch]

 On Oct 30, 2014, at 6:20 PM, Lester Caine les...@lsces.co.uk 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 do $foo[
 (string)$u_str ] = $bar; with the proposed RFC, you could do $foo[
 $u_str ] = $bar with the same result; but either way, you would still
 need to convert *back* to an object in order to use any of the UString
 methods in a foreach(), array_walk(), etc.
 
 I would still like to see the debate on proper use of unicode IN PHP
 strings. Pushing that problem into objects is just as wrong as this
 debate. If I'm using a unicode colation to sort a set of array keys then
 the KEY should be unicode, not yet another handle to a secondary object
 which the needs to be sorted ... but then perhaps we need this fiddle to
 avoid the complexity that unicode can create?

I agree it’s high time Unicode be in PHP, but we are calling this PHP 7 and not 
6 for a reason. The lessons learned in the difficulties of implementing Unicode 
directly in the language were a direct player in the death of PHP 6.  We need 
to keep that in mind as we’re continuing these types of discussions.

The only time I see this being an issue related to Unicode (short-term) is if 
we do not implement a language-integrated 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 will be on the 
implementation of Unicode and not so much this.

As it stands right now, the RFC wiki seems to have no references to Unicode 
implementation beyond 2010’s end of PHP6. 

 
 -- 
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

 On Oct 27, 2014, at 1:36 AM, Stas Malyshev smalys...@gmail.com 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 the name __toScalar, while today we'd only be using
 it for this, 
 __toScalar does not express the fact why we are calling it - to use it
 as a key. It's not just a scalar conversion, it's conversion for the
 purpose of hashing.

I think that’s the general confusion around this. Generally, the examples 
provided (Java/Ruby/Python) are based on two things:

1. The value returned is a signed 32-bit (debatable) integer
2. Each hash is calculated based on the properties available (and assigned). 

With this in mind, should we not expect, at the very least, and integer on each 
return?  For example:

class Company
{
private $companyId;
private $clientId;

public function __construct($companyId, $clientId)
{
$this-companyId = (int) $companyId;
$this-clientId = (int) $clientId;
}

public function __toHash()
{
return $this-companyId * $this-clientId;
}
}

This is a trivial example, it can be used to define a simple approach for 
object “uniqueness” and prevent potentially prevent duplicate hashes in a 
structure.

That said, with PHP’s typeless approach, I understand the case could be made 
for combining values into a string.  To me, it seems more logical and uniform 
to require an integer - whether signed or unsigned.

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


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

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

[Will Fitch]

 On Oct 26, 2014, at 4:21 PM, Stas Malyshev smalys...@sugarcrm.com 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
 have to implement MIME parsing from scratch. There are frameworks that
 implement that. Not everything must be written in C. But if you want C,
 doesn't pecl/http already have the required bits?

100% agree. Perhaps focusing on getting pecl/http v2 added as ext or core 
should be the real discussion: https://wiki.php.net/rfc/pecl_http 
https://wiki.php.net/rfc/pecl_http.

 
 Having the ability to access the data provided in $_POST for other methods
 is ideal (by whatever means: $_PUT, $_FORM, get_parsed_form_data(), etc).
 
 There are a lot of HTTP verbs - PUT, DELETE, TRACE, PATCH... And what if
 you want to do WebDAV? Wouldn't having separate superglobal for each be
 taking it a bit too far?
 
 -- 
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

[Will Fitch]

 On Oct 26, 2014, at 5:00 PM, Park Framework park.framew...@gmail.com wrote:
 
 2014-10-26 23:24 GMT+02:00 Florian Margaine flor...@margaine.com:
 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 single
 interface, do not make exceptions for POST, input data send methods
 PUT, DELETE, must be available in a single global variable, the
 variable name is not important
 file_get_contents(‘php://input') - uncomfortably

Or, use pecl/http to handle it.  GET/POST are form relative while all others 
are HTTP related. That’s been said quite a few times in this thread.  You don’t 
have to use php://input php://input. pecl/http is available.

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

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

[Will Fitch]

 On Oct 26, 2014, at 8:37 PM, Stas Malyshev smalys...@gmail.com 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 effectively provides a unique hash for an object. If the 
intent is to provide an opportunity of individual classes to decide what their 
hash is, couldn’t they provide that via __toString? I know many frameworks use 
__toString to build out some implementation of an object (Zend form for 
example), but the point of __toString is to provide a string representation of 
an object.

I want to say, I’m not at all against this - rather I support it.  I’m just 
looking for the RFC to provide an example that I and others can relate to.

 It was discussed in the past on the list:
 http://marc.info/?t=14114596961r=1w=2
 and I think it makes sense to propose a formal RFC for it. Both the text
 and the code in the patch includes bits done by myself and Joe Watkins.
 The patch does not cover 100% of cases but should work for most
 reasonable 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 disagreement.
 
 Thanks,
 Stas
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

 On Oct 26, 2014, at 9:43 PM, Stas Malyshev smalys...@gmail.com 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) and imagine you actually want two GMP objects expressing 42
 actually represent the same hash key. Or imagine you want to generate
 the key somehow in a way related to object's content and not just a
 random number. As I said 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/deprecating/removing spl_object_hash? I’m concerned these different 
approaches will introduce quite a bit of confusion with object hashing. This 
RFC’s approach gives the user more power to determine what’s best in this case, 
so I’d lean more towards renaming spl_object_hash to something that reflects 
getting a unique ID per object (e.g. spl_unique_object_id, etc).

 
 an object. If the intent is to provide an opportunity of individual
 classes to decide what their hash is, couldn’t they provide that via
 __toString? I know many frameworks use __toString to build out some
 implementation of an object (Zend form for example), but the point of
 __toString is to provide a string representation of an object.
 
 This is covered in the RFC, right in the introduction.
 -- 
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/


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

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

[Will Fitch]

 On Oct 26, 2014, at 10:38 PM, Sanford Whiteman figureone...@gmail.com 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/downloads/pecl/releases/http/ 
http://windows.php.net/downloads/pecl/releases/http/.  Did I miss something?

 
 -- S.

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

[Will Fitch]

On Thu, Mar 7, 2013 at 7:10 AM, Bob Weinand bobw...@hotmail.com wrote:

 Am 7.3.2013 um 00:32 schrieb Stas Malyshev smalys...@sugarcrm.com:

  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 incorrect claim that unset() is a
  function and that there's some inconsistency in the fact that it does
  not return value.
 
  Also, it is not clear what false returned from unset() actually means -
  did it fail to unset the value (i.e., it is still set) or there was
  nothing to unset (i.e., it is still not set)?
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php

 Hi!

 The main practical value is in the __unset magic method. You can now
 communicate through the proper way of a language construct with an
 __unset method. (success or failure)


The practical value in __unset is that you can unset an unavailable
property.  The goal of unset has never been to communicate anything.  It
simply destroys a variable.  Furthermore, if you're looking to identify,
based on your examples, if you need to do cleanup work if a variable is
set, your application should check to see if that value is set.  Unset is
part of the cleanup work itself.

It would be nice to see actual use cases in an application rather than
examples showing that your very specific use cases would work with this
change.  I've yet to see any value added by this RFC.



 I've added a code example to the RFC.

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

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

[Will Fitch]

On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com 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,

 Bob Weinand

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

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

[Will Fitch]

On Wed, Mar 6, 2013 at 4:40 PM, Ferenc Kovacs tyr...@gmail.com wrote:

 On Wed, Mar 6, 2013 at 10:38 PM, Ferenc Kovacs tyr...@gmail.com wrote:

 
 
 
  On Wed, Mar 6, 2013 at 10:10 PM, Bob Weinand bobw...@hotmail.com
 wrote:
 
  Hi!
 
  As this seem to require a RFC, here is it:
 
  https://wiki.php.net/rfc/unset_bool
 
  Please feedback,
 
  Bob Weinand
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
  unset is not a function, but a language construct, and there is at least
  one similar construct which doesn't return anything (eg. not returning
  NULL, but syntax error when used in a return context): echo
 
 
 referring to This removes also an inconsistency: the function's return
 value is void, states the docs. It is until now the only function which has
 no return value. especially.


Agreed.  The RFC needs to be updated as to not mislead readers.



 --
 Ferenc Kovács
 @Tyr43l - http://tyrael.hu

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

[Will Fitch]

On Wed, Mar 6, 2013 at 5:25 PM, Bob Weinand bobw...@hotmail.com wrote:

 Am 6.3.2013 um 22:50 schrieb Will Fitch willfi...@php.net:

 On Wed, Mar 6, 2013 at 4:44 PM, Bob Weinand bobw...@hotmail.com wrote:

 Am 06.03.2013 um 22:39 schrieb Will Fitch willfi...@php.net:

 On Wed, Mar 6, 2013 at 4:10 PM, Bob Weinand bobw...@hotmail.com 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,

 Bob Weinand

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


 I don't see here a real need for a benchmark as it is mostly only
 returning SUCCESS or FAILURE instead of nothing. Nothing what would slow
 PHP down.


 Any change to a language construct which requires additional processing
 adds time.  It may be in minute, but it's part of the discussion.  Since
 this core change you're requesting comments for introduces a usecase which
 many will not find useful (probably most voting), it is your responsibility
 to convince this category of people that the tradeoff won't affect them
 that much.

 If you choose not to add benchmarking, I will guarantee a -1 from me.



 Bob Weinand


 I have tried the following:

 time ./sapi/cli/php -r 'while($i++  1e7) { $a = true; unset($a); }'

 Unpatched: average of 5x executed:
 real 0m4.935s
 user 0m4.925s
 sys 0m0.008s

 Patched: average of 5x executed:
 real 0m4.945s
 user 0m4.938s
 sys 0m0.005s


 Yes, there is an increase of 0.15%. This is 1 nanosecond more than
 previous.

 Is this exact enough? Or do you need more precision?

 If yes, I'll put this into the RFC.


Thank you.  Please do add to the RFC




 Bob Weinand

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

[Will Fitch]

On Feb 19, 2013, at 8:00 AM, Sara Golemon poll...@php.net wrote:

 On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
 ro...@kingsquare.nl 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://wiki.php.net/rfc/skipparams)
 
 That way it would be consistent with this RFC and the list() construct ?
 
 It's orthogonal to skipparams.  It'd neither help nor hurt based on
 the recommendations of that RFC.
 
 With regard to list(), it already supports expressions like this:
 list($x,) = array(123); so nothing more needs to be done for it and
 it's not at odds with either of these RFCs.

I would vote +1 on this solely for the sake of consistency.  I've never liked 
the idea behind the parser's actions on constructs (list, array).

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


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

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

[Will Fitch]

On Feb 19, 2013, at 6:01 PM, Zeev Suraski z...@zend.com 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 adding/removing/changing syntax, that
 goes well beyond 'because we can' or 'it shortens the code' it
 shouldn't even be brought up for discussion.
 
 Zeev
 
 On 19 בפבר 2013, at 19:44, Nikita Nefedov inefe...@gmail.com wrote:
 
 Hi!
 
 As someone mentioned in the thread about short syntax for closures, we could 
 also drop requirement for `function` keyword when defining/declaring methods 
 in classes, interfaces or traits.
 
 I have long noticed how redundant it is. The patch is pretty 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 karma for making RFC.
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

Re: [PHP-DEV] Purpose of voting

[Will Fitch]

On Jan 28, 2013, at 2:14 PM, Anthony Ferrara ircmax...@gmail.com 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?

Personally, I'm discussing/voting on the feature.  We do tend to combine our 
discussions, but voting seems to be directly for the proposed feature.  I don't 
necessarily disagree with this approach, as we tend to hash out the 
implementation during the discussions.  It might save RFC authors a lot of time 
and keyboard taps if we discussed/voted on a feature prior to discussing 
implementation.  This could open the door for a flood of feature requests in 
the form of RFCs, but I don't believe that would happen.

One of the advantages of combining the patch(es) with an RFC is it shows the 
author has put forth an effort in thinking the idea through.  That said, a 
rule of thumb (or official rule) that RFC authors should provide a patch once 
the feature has been approved might work.  

In the end, separating the two would end up saving the RFC's author and this 
list time as to whether a feature should be considered.  However, there are 
times where the implementation could change the outcome of the feature vote 
itself.

 
 I've always approached it as we're voting for the concept (and details)
 provided in the RFC. But it appears that other people have been voting on
 the specifics of the attached patch (so theoretically an RFC could be
 rejected entirely because some people don't like part of the implementation
 in C, but are fine with the PHP details).
 
 I'll leave out my opinion (and justification) for now, I'm curious what you
 all think...
 
 Thoughts?
 
 Anthony


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

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

[Will Fitch]

On Jan 25, 2013, at 11:25 AM, Zeev Suraski z...@zend.com 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
 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 the Optimizer+ component which is
 current, a bit faster than APC, worked with PHP 5.4 from the get go and
 already fully supports 5.5 - and now that it's been free for use for
 several years, we'd actually be happy to opensource it and make it a part
 of core.  An extra benefit would be that we'd commit to maintain it,
 although of course, community contribution will be very welcome.
 Here too, it's code with a very long history, some of which even predates
 PHP 4.0.  But It Works(tm), and we could put some effort into cleaning it
 up and beautifying it.

I like the idea.  If this was implemented in core, and the need for APC opcode 
caching disappeared, would APC still be actively maintained for userland 
functions (e.g. apc_store, apc_*)? 

 I think we can actually do it on time for 5.5.0, or with a relatively
 minor delay that might be worth it.  I'm sure most users would prefer the
 version to take a bit longer if it comes with an opcode cache right off
 the bat.
 There'll most probably be APIs we'd want to merge from APC, but doing that
 should be easy - and we can get the good of both worlds.
 
 Zeev
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

On Jan 25, 2013, at 11:52 AM, Julien Pauli jpa...@php.net wrote:

 On Fri, Jan 25, 2013 at 5:47 PM, Will Fitch willfi...@php.net wrote:
 
 On Jan 25, 2013, at 11:25 AM, Zeev Suraski z...@zend.com 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
  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 the Optimizer+ component which is
  current, a bit faster than APC, worked with PHP 5.4 from the get go and
  already fully supports 5.5 - and now that it's been free for use for
  several years, we'd actually be happy to opensource it and make it a part
  of core.  An extra benefit would be that we'd commit to maintain it,
  although of course, community contribution will be very welcome.
  Here too, it's code with a very long history, some of which even predates
  PHP 4.0.  But It Works(tm), and we could put some effort into cleaning it
  up and beautifying it.
 
 I like the idea.  If this was implemented in core, and the need for APC 
 opcode caching disappeared, would APC still be actively maintained for 
 userland functions (e.g. apc_store, apc_*)?
 
 Well, the APC idea was anyway to merge an Opcode cache to Core, and only an 
 Opcode cache (correct if I'm wrong).
 apc_store() etc... are userland shared memory function, and should be 
 migrated into another extensions, on which we could then allocate devs to 
 work on, new ideas, etc…

No, you're right.  With Optimizer+ showing a slightly better performance than 
APC, being privately and publicly maintained, open-sourced, already 
compatible up to 5.5, I see it as a great candidate for core integration.  I'd 
still like to keep APC as a separate extension, but packaged with PHP, for 
data-only caching.

@Zeev, is anyone writing up an RFC for this?

 
 Julien.Pauli

Re: [PHP-DEV] new FTP function

[Will Fitch]

On Jan 18, 2013, at 9:53 AM, KISE wowk...@gmail.com 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 use ftp_chdir() just to check if the directory
 exists, because its shows errors if the directory doesn't exists. i think
 there should be a way to check if the directory exists without having to
 resort to hackish ways, or having to authenticate again.

There are procedures in place for this.  If you'd like to make a feature 
request, use bugs.php.net and submit the request with the FTP extension 
selected.  You can also use https://wiki.php.net/rfc if you really want to 
see/make the change as well.

Re: [PHP-DEV] How about implementing more data structures (ie Map, Set)

[William Fitch]

On Dec 18, 2012, at 9:43 AM, Victor Berchet vic...@suumit.com wrote:

 Dear all:
 
 I would like to get your feedback on implementing some more data structure in 
 the PHP core.
 
 Things like Set, Map could be really helpful.
 
 A Set would be an unordered collection with no duplicate elements (same as in 
 Python)
 
 $setA = new Set();
 $setA-append('a');
 $setA-append('a');
 
 $setB = new Set();
 $setB-append('b');
 
 $setA == $setB;
 
 // A set can hold objects
 $set-append($object);
 
 A Map would be an associative array that can hold objects (same as Python 
 dictionaries)
 
 $map= new Map();
 
 $map[$setA] = 'Hello, world!';
 echo $maps[$setB]; // Hello, world !

Most of what you're looking for can be accomplished by implementing ArrayAccess 
in your own classes, or using the ArrayObject generically like so:

php  $obj = new ArrayObject(array());
php  $obj-append('some string');
php  $obj-append(new ArrayObject(array()));
php  var_dump($obj[1]);
class ArrayObject#4 (0) {
}
php  var_dump($obj[0]);
string(11) some string

For the duplicate issue you're referring to, you'd need to implement your own 
methods for removing (e.g. array_unique).

 
 I can not really help with the implementation, however I could help defining 
 the API, creating a test suite and docs should this idea be accepted.
 
 Note: I had to implement this in PHP while working on Automaton, it's tedious 
 and inefficient.
 
 Thanks for your feedback,
 Victor
 
 
 


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

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

[Will Fitch]

On Wed, Dec 5, 2012 at 6:18 AM, Amir ad...@ecdcconference.org 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 document, I confused with zend engine source code and c++ and
 relations with php.
 I just have a simple question, how can I use mysql funtions work with query
 and process it like:
 mysql_query
 mysql_fetch_assoc
 and ...


Are you specifically referring to using mysql functions, or are you
referring to executing user space functions?  It looks like you're
specifically referring to MySQL functions, and in that case, you should
look at ext/mysqlnd or libmysql.  Executing user space functions in this
manner is not a good route to take.

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 selectDB, *args_selectDB[1], retval;

 /*if(zend_call_method(NULL, NULL,
 NULL,
 mysql_connect,

 strlen(mysql_connect),
 retval,
 1,
 args[1],
 args[2] TSRMLS_CC
 )
 == FAILURE) {
 php_printf(gosh!);
 }
 else {
 php_printf(yep!);
 }*/


 ZVAL_STRING(fname, mysql_connect, 0);

 MAKE_STD_ZVAL(args[0]);
 ZVAL_STRING(args[0], localhost, 1);

 MAKE_STD_ZVAL(args[1]);
 ZVAL_STRING(args[1], root, 1);

 MAKE_STD_ZVAL(args[2]);
 ZVAL_STRING(args[2], , 1);


 if (call_user_function(EG(function_table), NULL, fname, dbLink, 3,
 args TSRMLS_CC) == FAILURE) {

 RETURN_STRING(fail to connect to database, 1);
 }
 else
 {
 zval_ptr_dtor(args[2]);
 zval_ptr_dtor(args[1]);
 zval_ptr_dtor(args[0]);

 /*
 *return_value = dbLink;
 zval_copy_ctor(return_value);
 */

 /now! I want to select a database on success/

 ZVAL_STRING(selectDB, mysql_select_db, 0);

 MAKE_STD_ZVAL(args_selectDB[0]);
 ZVAL_STRING(args_selectDB[0], clickbartarirg, 1);

 if (call_user_function(CG(function_table), NULL, selectDB,
 retval, 1, args_selectDB TSRMLS_CC) == SUCCESS)
 {
 /* I successfully selected database */
 ZEND_FETCH_RESOURCE_NO_RETURN(retval);
 if(retval)
 {
 php_printf(selected);
 }
 else
 {
 zend_error(E_ERROR, failed to select database!);
 }

 zval_ptr_dtor(args_selectDB[0]);

 }
 else
 {
 zend_error(E_ERROR, database problem);
 zval_ptr_dtor(args_selectDB[0]);
 }
 }

 }

 Thanks.

 Regards
 *Amir Ghazavi*
 *Web Developer
 IT Manager of ECDC2013*
 *
 *
 *www.ecdcconference.org*

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

[Will Fitch]

On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 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 be able to do a

thing about it? How is it good for them?


I don't mean to state the obvious, but wouldn't display_errors = 'Off' in
production or error_reporting = E_ALL ^ E_DEPRECATED be sufficient?  This
is the same approach taken with register_globals - and it happened between
5.3 and 5.4.



 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

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

[Will Fitch]

On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:

 On 11/15/2012 11:53 AM, Will Fitch wrote:
  On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev smalys...@sugarcrm.com
 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 be able to do a
 
  thing about it? How is it good for them?
 
 
  I don't mean to state the obvious, but wouldn't display_errors = 'Off' in
  production or error_reporting = E_ALL ^ E_DEPRECATED be sufficient?  This
  is the same approach taken with register_globals - and it happened
 between
  5.3 and 5.4.

 Actually, no it wouldn't. You still get the overhead of the error, plus
 any custom error handlers will be triggered regardless of the
 error_reporting setting which depending on the implementation of the
 error handler can be quite costly performance-wise.


So what solution is there to this? Should it not be deprecated? This same
issue (is still happening) with register_globals for us, but it's
acceptable as it has been phased out.  Should there be no deprecation
warning now and wait for a future release?



 -Rasmus

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

[Will Fitch]

On Thu, Nov 15, 2012 at 3:11 PM, Rasmus Lerdorf ras...@lerdorf.com 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 error handlers will be triggered regardless of the
  error_reporting setting which depending on the implementation of the
  error handler can be quite costly performance-wise.
 
  So what solution is there to this? Should it not be deprecated? This
  same issue (is still happening) with register_globals for us, but it's
  acceptable as it has been phased out.  Should there be no deprecation
  warning now and wait for a future release?

 I'd like to see usage drop off first so we aren't negatively affecting
 millions of sites performance-wise, and/or we streamline the error
 handling code so there is a way to avoid this performance hit.


This makes sense, but from an engineering standpoint, what can be used as a
trigger to move to a more recent driver outside of deprecation?  I'm not
sure there is another solution.

Your argument is valid.  The question of, why do we deprecate something
that is so heavily used comes to mind, but in the end, this is a something
the extension maintainers want - not end users.  Maybe the correct solution
is to hand off the maintenance of this extension to a new team?



 -Rasmus

Re: [PHP-DEV] pdo_pgsql Boolean Issues

[Will Fitch]

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 willfi...@php.net wrote:

 Going to bump this thread.

 https://bugs.php.net/bug.php?id=62593
 https://github.com/php/php-src/pull/198

 The pull request hasn't had feedback in over a week, and I'd like to make
 some progress as this is preventing some from moving to 5.3/5.4.


 On Fri, Sep 21, 2012 at 10:52 AM, Wez Furlong w...@wezfurlong.org 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 wfi...@meetme.com wrote:
  Thanks, Pierre -  The PR can be found at
  https://github.com/php/php-src/pull/198

Re: [PHP-DEV] pdo_pgsql Boolean Issues

[Will Fitch]

Going to bump this thread.

https://bugs.php.net/bug.php?id=62593
https://github.com/php/php-src/pull/198

The pull request hasn't had feedback in over a week, and I'd like to make
some progress as this is preventing some from moving to 5.3/5.4.

On Fri, Sep 21, 2012 at 10:52 AM, Wez Furlong w...@wezfurlong.org 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 wfi...@meetme.com wrote:
  Thanks, Pierre -  The PR can be found at
  https://github.com/php/php-src/pull/198

Re: [PHP-DEV] pdo_pgsql Boolean Issues

[Will Fitch]

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 pierre@gmail.com wrote:

 hi Will,

 On Mon, Sep 17, 2012 at 7:45 PM, Will Fitch willfi...@php.net wrote:

  While I've spent the better part of a week trying to determine the best
  solution, I want to run this by Ilia, Wez and/or Edin for input.  Anyone
  else on the list is also encouraged to provide feedback as well.

 Thanks for your detailed report!

 Could you please open a bug report and attach the bug to it please? It
 will be much easier to track and fix the issue(s).

 You can also create a pull request on github as this patch may need
 some work or testing (incl. adding tests). It could be easier to have
 a PR then.

 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

[PHP-DEV] Is Git Down?

[Will Fitch]

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

[PHP-DEV] pdo_pgsql Boolean Issues

[Will Fitch]

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 happens
when the libpq version  8.0
2. PQprepare is available, but either
PDO_PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT
or PDO_ATTR_EMULATE_PREPARES are true (emulation handled by PDO, and the
parameter hook pgsql_stmt_param_hook just skips parameter checks)

This results in PDO converting the parameter to a long (default behavior
for boolean).  Take the following example:

$pdo = new PDO($dsn);
$pdo-setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
$query = $pdo-prepare( 'SELECT :foo IS FALSE as val_is_false' );
$query-bindValue( ':foo', false, PDO::PARAM_BOOL );
$query-execute( );
print_r($query-errorInfo());

This results in the following:

Array
(
[0] = 42804
[1] = 7
[2] = ERROR:  argument of IS FALSE must be type boolean, not type
integer at character 8
)

This happens because true and false are converted to their long formats (1
and 0 respectively), which are invalid values for Postgres.  However, in
the sole event that PQprepare is available and emulation is disabled,
boolean parameters are correctly converted to t and f.

As noted in bug #62593, disabling emulation fixes the 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 statements.  The calls
from PQprepare and PQexec will have separate handles.

The attached patch updates the driver to behave like so:

1. Do we have PQprepare and is emulation turned off?  If so, let the driver
handle via PQprepare and PQexec
2. Is PQprepare unavailable? If so, modify the original param by replacing
the long 1 or 0 format to t or f
3. Is PQprepare available and emulation turned on? If so, modify the
original param by replacing the long 1 or 0 format to t or f

While I've spent the better part of a week trying to determine the best
solution, I want to run this by Ilia, Wez and/or Edin for input.  Anyone
else on the list is also encouraged to provide feedback as well.

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

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

[Will Fitch]

On Fri, Sep 7, 2012 at 1:24 PM, Mark mark...@gmail.com wrote:

 On Fri, Sep 7, 2012 at 8:22 AM, Lester Caine les...@lsces.co.uk 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
  the spec. I understand the RFC full well and know why the design is
  the way it is. I was answering the ops question. Please read what I
  said before you make your own assumptions.
 
 
  Sorry, statements like haphazard way, never well designed, it's a
  mess, they don't really resemble namespaces, just some fancy magic,
  etc. have nothing to do with facts. Actually, facts are exactly the
  opposite - they were designed, were extensively discussed with
  soliciting feedback from many stakeholders, and were implemented exactly
  as planned. You may not like the way there were implemented, that's your
  opinion (not a fact) and you are entitled to it. But you didn't limit
  yourself to saying I don't like them. You specifically said that they
  were never well designed and haphazardly implemented. This is factually
  false.
 
 
  Stas ... One thing to bear in mind is that even for those of us for whom
  English is our only language it is sometimes difficult to explain what we
  mean. Sherif's were perhaps a little 'provocative' but were an accurate
  reflection of his view on the results of implementing namespaces. It is a
  compromise rather than something that sits naturally in PHP?
 
  What a lot of newcomers need to understand is that PHP is NOT compiled,
 so a
  heck of a lot of what they are used to just happening is physically
  impossible, and namespace is a good case in point. Personally I have yet
 to
  see a good example of the use of namespaces in third party libraries, and
  like Sherif avoid them preferring simply so that while the code may be
 more
  verbose, it's clear 5 years later what was intended :) A lot of the
 current
  'magic' makes it difficult to pick up and work with other peoples code
 later
  on.

 Right, i have to correct you there.
 You don't explicitly say it, but you do think that i'm a newcommer.
 That's far from the truth. I've been using PHP since 2001 and i
 consider myself to be quite advanced in PHP usage.

 Back on the namespace topic. I won't judge on anything, but i know
 namespaces from c++. I understand that PHP isn't a compiled language
 and quite frankly that doesn't matter at all. What does matter is that
 PHP uses the name: namespace which C++ obviously had earlier.
 Naturally someone that knows both languaes (c++ and php) simply assume
 that a namespace in php probably works the same as those in C++. If
 that's not the case then it shouldn't even carry the namespace name.


Right, I have to correct you there. Just because a namespace doesn't act
like C++'s namespace implementation doesn't mean it's not a namespace.  A
namespace is just an abstract container which groups unique symbols
(names).  The PHP implementation does exactly that.



 To me this namespace in php stuff just looks like and alias. So why
 isn't it named as that: alias? I do not want to question the ones
 that implemented namespaces in php, but i do think that the name
 itself is at the very least confusing.


Because it behaves as a namespace.  Again, just because the implementation
isn't what you're used to, or even like, it still groups identifiers in
abstract containers.  I realize that the implementation and ZE backend may
cause some confusion with 'aliasing', but it's use case is the same.

Also note:

use Some\Ns\Class as MyClass;

There's an alias for you. ;)



 Also, lets keep this discussion polite people. I'm not here to smash
 toes. All i would like to know is the reasoning behind the above and
 if there is any intention of changing the namespaces to be more c++
 like.

 Cheers,
 Mark

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

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

[Will Fitch]

On Fri, Sep 7, 2012 at 1:24 PM, Mark mark...@gmail.com wrote:

 On Fri, Sep 7, 2012 at 8:22 AM, Lester Caine les...@lsces.co.uk 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
  the spec. I understand the RFC full well and know why the design is
  the way it is. I was answering the ops question. Please read what I
  said before you make your own assumptions.
 
 
  Sorry, statements like haphazard way, never well designed, it's a
  mess, they don't really resemble namespaces, just some fancy magic,
  etc. have nothing to do with facts. Actually, facts are exactly the
  opposite - they were designed, were extensively discussed with
  soliciting feedback from many stakeholders, and were implemented exactly
  as planned. You may not like the way there were implemented, that's your
  opinion (not a fact) and you are entitled to it. But you didn't limit
  yourself to saying I don't like them. You specifically said that they
  were never well designed and haphazardly implemented. This is factually
  false.
 
 
  Stas ... One thing to bear in mind is that even for those of us for whom
  English is our only language it is sometimes difficult to explain what we
  mean. Sherif's were perhaps a little 'provocative' but were an accurate
  reflection of his view on the results of implementing namespaces. It is a
  compromise rather than something that sits naturally in PHP?
 
  What a lot of newcomers need to understand is that PHP is NOT compiled,
 so a
  heck of a lot of what they are used to just happening is physically
  impossible, and namespace is a good case in point. Personally I have yet
 to
  see a good example of the use of namespaces in third party libraries, and
  like Sherif avoid them preferring simply so that while the code may be
 more
  verbose, it's clear 5 years later what was intended :) A lot of the
 current
  'magic' makes it difficult to pick up and work with other peoples code
 later
  on.

 Right, i have to correct you there.
 You don't explicitly say it, but you do think that i'm a newcommer.
 That's far from the truth. I've been using PHP since 2001 and i
 consider myself to be quite advanced in PHP usage.

 Back on the namespace topic. I won't judge on anything, but i know
 namespaces from c++. I understand that PHP isn't a compiled language
 and quite frankly that doesn't matter at all. What does matter is that
 PHP uses the name: namespace which C++ obviously had earlier.
 Naturally someone that knows both languaes (c++ and php) simply assume
 that a namespace in php probably works the same as those in C++. If
 that's not the case then it shouldn't even carry the namespace name.

 To me this namespace in php stuff just looks like and alias. So why
 isn't it named as that: alias? I do not want to question the ones
 that implemented namespaces in php, but i do think that the name
 itself is at the very least confusing.

 Also, lets keep this discussion polite people. I'm not here to smash
 toes. All i would like to know is the reasoning behind the above and
 if there is any intention of changing the namespaces to be more c++
 like.


Also forgot to throw this in:
http://marc.info/?r=1q=bl=php-internalss=namespace+implementationw=3.
 This topic was discussed over a long period of time, and if you truly want
to understand the logic behind it, please read all the threads.



 Cheers,
 Mark

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

Re: [PHP-DEV] On BC and interfaces

[Will Fitch]

On Thu, Sep 6, 2012 at 2:43 PM, Kris Craig kris.cr...@gmail.com wrote:

 On Tue, Sep 4, 2012 at 12:15 AM, Stas Malyshev smalys...@sugarcrm.com
 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.google.com/115250422803614415116/posts/hMT5kW8LKJk
 
  It talks about Linux kernel and discussion has next to nothing to do
  with PHP, but generic point about keeping the interfaces and importance
  of not serving one use case I think very important for all widely used
  platforms equally. I think the opinion of the author of one of the most
  successful platforms in recent history may be interesting to consider.
  --
  Stanislav Malyshev, Software Architect
  SugarCRM: http://www.sugarcrm.com/
  (408)454-6900 ext. 227
 
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 This is why I love Mr. Torvalds!  Unlike people like Jobs and Gates, Linus
 stands firmly against the whole, We know what's best for you better than
 you do mentality.

 My newly-acquired Kindle Fire pissed me off last night.  I turned it on to
 watch an episode of Futurama and read some pages from Hawking's The Grand
 Design before bed, then out of nowhere it rebooted itself and began an
 update process that took the better part of 30 minutes!  I was forced to
 skip Futurama and just go straight to the origins of the universe.  Fucking
 bastards  /rant


You win the most random rant of the year award, Kris.



 --Kris

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

[Will Fitch]

On Wed, Sep 5, 2012 at 4:14 AM, Lester Caine les...@lsces.co.uk 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 (America/Chicago)


 Just working through another backlog of 'todo' items.

 Your current RFC includes -0500 in the examples, but that is purely due to
 your own setup. This is the real problem here since you can't take a
 date/time string and clone a new object. You have to define a DateTimeZone
 object prior to creating the DaTime object. You have 'America/Chicago' set
 as your default timezone, and that is fine for your local working, but part
 of Derick's objection is that how this all hangs together is always a two
 stage process.

 Now if you can make the above string clone a matching
 DateTime/DateTimeZone object pair, then part of the objection would go, but
 *I* would still object to any default here since it's just as likely you
 want to leave the timezone off and handle it separately as include it in an
 output string.

 Also it is worth noting that DateTime::__construct specifically ignores
 the $timezone parameter when the date string includes an offset! This may
 well be considered a bug and perhaps $timezone parameter should take
 priority, but it's all these little things that get missed when one 'just
 fills in a missing function' ... someone just taking the default string and
 trying to create a new date object for a different timezone might get
 caught out, so that particular point should be included in any
 documentation. Actually currently the returned string would not work anyway?


The format being suggested (ISO8601 + TZ name) won't work without
addressing the concern you mentioned as well as correctly parsing the TZ
name.



 The RFC is 'needs more work' but I still feel that adding this 'shortcut'
 will create more problems than it will provide any benefit.


I'm currently working on revamping the RFC and offering up two separate
solutions.  You are right that it's going to be difficult to please
everyone, but I do want a solution that can be acceptable to most.  If that
ends up being no solution at all, so be it.  I do believe through enough
conversation and potentially adjusting DateTime's current behavior (e.g.
the TZ point you brought up), a solution can be reached.

It's important to keep one of Derick's points in mind as well -
https://wiki.php.net/rfc/datetime_and_daylight_saving_time.




 --
 Lester Caine - G8HFL
 -
 Contact - 
 http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - 
 http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk



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

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

[Will Fitch]

On Mon, Sep 3, 2012 at 4:16 AM, Derick Rethans der...@php.net wrote:

 On Sun, 2 Sep 2012, Will Fitch wrote:

  On Sep 2, 2012 6:08 PM, Lester Caine les...@lsces.co.uk 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
   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 format().
  
  
   Hopefully Will now understands just how problematic his request is, and
  why it has not been implemented as yet. I'm with you but for a slightly
  different reason. I never run anything but UTC on the server. So I'm only
  displaying anything other than UTC when handling a client view of the
 data.
  So I would normally be calling format with the client timezone data.
 
  It is problematic because that is what we choose to make it. Right now,
  a
  catchable fatal error is produced. That is problematic. ISO8601 is not
  lossy nor is UTC.

 This tells me you haven't researched this subject properly. So let me
 demonstrate once more:


 $d = date_create( 2012-09-03 09:13:52 );
 var_dump( $d );
 $s = $d-format( DateTime::ISO8601 );
 $d = date_create( $s );
 var_dump( $d );

 Outputs:

 class DateTime#1 (3) {
   public $date =
   string(19) 2012-09-03 09:13:52
   public $timezone_type =
   int(3)
   public $timezone =
   string(13) Europe/London
 }

 class DateTime#2 (3) {
   public $date =
   string(19) 2012-09-03 09:13:52
   public $timezone_type =
   int(1)
   public $timezone =
   string(6) +01:00
 }

 And voila, you've just lost the timezone that belongs to the DateTime
 object.


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.  The DateTime object still maintains its integrity
- and includes the offset (if present).  The toString representation is not
a serialized format of every attachment of the entire object - it's a
string representation.

You actually helped prove the case for ISO-8601, IMHO.  You were able to
take the date, time and UTC offset and accomplish the same goal; all of
this from the toString format!



  We have standards for a reason. I agree that changing that should not
  be allowed. I will remove the set/get pattern functions and only print
  a standard format. Printing an ISO standard format, which includes the
  TZ based on UTC, or even the UTC format itself is a better solution
  than a catchable fatal error.

 I disagree as it is an Ostrich Method. Instead of fixing your problem
 you'll just be hiding it.

 Derick

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

[Will Fitch]

On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue li...@rotorised.com 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-09-02T18:19:05+0100 (Africa/Niamey)


Disagree - The ISO8601 provides a good *string* representation of the
object.  If you want every aspect of the entire object, including the
properties which are also objects, serialize it.



 --
 Ryan McCue
 http://ryanmccue.info/

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

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

[Will Fitch]

On Mon, Sep 3, 2012 at 5:45 AM, Adam Harvey ahar...@php.net wrote:

 On 3 September 2012 17:36, Andrew Faulds a...@ajf.me wrote:
  Ryan McCue li...@rotorised.com 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)
 
 
  Sounds good.

 If we're going to invent arbitrary non-standard formats, why don't we
 just tell people to use json_encode($dateTime) and be done with it?

 I just don't see how we can choose a sensible default format for
 users. Sometimes you want ISO 8601. Sometimes you want whatever your
 locale's customary date format is. Sometimes you want US m/d/y dates
 for interacting with legacy systems. RFC 2822. RFC 822, natch. And so
 on. I don't see why one format should be blessed over others and have
 magic behaviour when a DateTime object is cast to a string. IMO, the
 fact that users have to provide a format string and call format() is a
 good thing: explicit beats implicit, every day of the week.


You absolutely made the case for using DateTime::format() - which is not
the proposal here.  This is for a string representation of the object via
toString.



 No matter what format string you use to iterate over said days.

 Adam

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

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

[Will Fitch]

On Mon, Sep 3, 2012 at 7:57 AM, Pierre Joye pierre@gmail.com wrote:

 hi Will,

 On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wfi...@meetme.com wrote:
  On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue li...@rotorised.com 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-09-02T18:19:05+0100 (Africa/Niamey)
 
 
  Disagree - The ISO8601 provides a good *string* representation of the
  object.  If you want every aspect of the entire object, including the
  properties which are also objects, serialize it.

 I don't think you will ever get a consensus on that. The reason is
 that this case falls in the same fall than the timezone itself (but
 per instance of an object instead of globally).

 I'd to suggest to force the definition of a format using the
 setStringFormat (or whatever will be the name of this function).
 __toString will then fail if no format has been set, warning and
 returns NULL (f.e.).


I actually feel a static function which tracks globally would best serve
this case:

date_default_format_set('c')

This would prevent the need for setting it on a per instance basis -
similar to the way timezones can be set:

date_default_timezone_set('America/Chicago')



 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

[Will Fitch]

On Mon, Sep 3, 2012 at 8:09 AM, Lars Strojny l...@strojny.net wrote:

 Hi Pierre, hi Will,

 Am 03.09.2012 um 13:57 schrieb Pierre Joye pierre@gmail.com:

  hi Will,
 
  On Mon, Sep 3, 2012 at 1:51 PM, Will Fitch wfi...@meetme.com wrote:
  On Mon, Sep 3, 2012 at 4:59 AM, Ryan McCue li...@rotorised.com 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-09-02T18:19:05+0100 (Africa/Niamey)
 
 [...]
 
  I don't think you will ever get a consensus on that. The reason is
  that this case falls in the same fall than the timezone itself (but
  per instance of an object instead of globally).
 
  I'd to suggest to force the definition of a format using the
  setStringFormat (or whatever will be the name of this function).
  __toString will then fail if no format has been set, warning and
  returns NULL (f.e.).


 I don’t agree here, especially if we recap what the proposed purpose of
 the __toString() method was:

   Ease debugging by allowing echo $date; instead of echo
 $date-format(...);

 An additional constraint to make sure users use it for debugging and
 nothing else, would be:

   Not allow changing the format, neither by ini setting or any other
 global means (incl. setters)

 To achieve that, we need a time format that is best for debugging,
 meaning, as lossless as possible. While ISO8601 comes pretty close it
 misses out on the Olson timezone suffix. I would second the notion of
 creating our own format and standardizing it internally with it’s own
 constant and DateTime doing the right thing if passed to the constructor.
 Additionally to what Ryan proposed, microseconds should be part of it
 (which ISO allows). So, here we go:

   2012-09-02T18:17:36.12345+0100 (Europe/London)


Hi, Lars - there wouldn't be a need for the offset if the string provides
the timezone name.  Parsing this wouldn't be an issue, however, it would be
harder to sell this approach to others.



 Following this, the change would be fairly easy (adding a constant, a bit
 parsing fu and the toString() method).

 cu,
 Lars

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

[Will Fitch]

On Mon, Sep 3, 2012 at 8:28 AM, Lester Caine les...@lsces.co.uk 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 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 setting. Personally I get around
 this problem by displaying a 'local client time' based on extra details
 provided by the client login. A server default is never going to be the
 right answer unless you simply switch off ALL timezone working and only use
 local time, in which case your proposal could work - as long as it NEVER
 displays offsets. Most problems on systems that DO require to correctly
 manage timezone shifted data come about by not running the server with a
 fixed UTC clock and then trying to map things across different timezones.
 In this situation, the browser time offset is useless and the main reason
 that Derick is flagging ISO format as lossy. It can never give you the
 correct data in six months time where daylight saving shifts comes in and
 using it here is just exacerbating that problem by continuing to reinforce
 a wrong 'standard'.

 So the server 'default' local time needs to work of extra timezone data
 rather than the local clock. Any display MUST then show timezone rather
 than just an arbitrary offset or simply UTC time ... with a UTC flag to
 confirm that.


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 (America/Chicago)




 --
 Lester Caine - G8HFL
 -
 Contact - 
 http://lsces.co.uk/wiki/?page=**contacthttp://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - 
 http://rainbowdigitalmedia.co.**ukhttp://rainbowdigitalmedia.co.uk



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

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

[Will Fitch]

On Sep 2, 2012 4:39 PM, Andrew Faulds a...@ajf.me 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_timezone_set(Africa/Niamey); echo
date_create()-format(DateTime::ISO8601), \n;'
 2012-09-02T18:19:05+0100

 vs:

 $ php -r 'date_default_timezone_set(Africa/Niamey); echo
date_create(2012-12-31)-format(DateTime::ISO8601), \n;'
 2012-12-31T00:00:00+0100
 ^

 $ php -r 'date_default_timezone_set(Europe/London); echo
date_create(2012-12-31)-format(DateTime::ISO8601), \n;'
 2012-12-31T00:00:00+
 ^

 I'm a little confused as to what is going on here, but ISO8601 has a UTC
format, -MM-DDTHH:MM:SSZ.

I think the issue on most minds is the TZ aspect. I agree with the others
on using UTC. I also think ill suggest a different approach to this.


 cheers,
 Derick



 --
 Andrew Faulds
 http://ajf.me/

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

[Will Fitch]

On Sep 2, 2012 6:08 PM, Lester Caine les...@lsces.co.uk 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
 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 format().


 Hopefully Will now understands just how problematic his request is, and
why it has not been implemented as yet. I'm with you but for a slightly
different reason. I never run anything but UTC on the server. So I'm only
displaying anything other than UTC when handling a client view of the data.
So I would normally be calling format with the client timezone data.

It is problematic because that is what we choose to make it. Right now,  a
catchable fatal error is produced. That is problematic. ISO8601 is not
lossy nor is UTC. It can be taken by any other language and converted based
on the format itself.

We have standards for a reason. I agree that changing that should not be
allowed. I will remove the set/get pattern functions and only print a
standard format. Printing an ISO standard format, which includes the TZ
based on UTC, or even the UTC format itself is a better solution than a
catchable fatal error.



 --
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

[PHP-DEV] RFC for Adding __toString to DateTime

[Will Fitch]

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 may be changed via setDefaultPattern and date_default_pattern_set,
as explained in the RFC.

The link to the RFC and patch are here:
https://wiki.php.net/rfc/datetime_tostring.

While I know this isn't as interesting as many of the current proposals
going on, I'm hoping you can give this RFC a look.

- Will

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

[Will Fitch]

On Sat, Sep 1, 2012 at 6:36 AM, Pierre Joye pierre@gmail.com wrote:

 hi Will,

 On Sat, Sep 1, 2012 at 12:14 PM, Will Fitch willfi...@php.net 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 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 may be changed via setDefaultPattern and
 date_default_pattern_set,
  as explained in the RFC.
 
  The link to the RFC and patch are here:
  https://wiki.php.net/rfc/datetime_tostring.
 
  While I know this isn't as interesting as many of the current proposals
  going on, I'm hoping you can give this RFC a look.

 It would be better to name the format method setDefaultFormat instead
 of setDefaultPattern, to be consistent with the rest of the API.


This makes sense. I'll update.



 (not saying I like the idea or not, only a 1st comment :)

 Cheers,
 --
 Pierre

 @pierrejoye

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

[Will Fitch]

On Sat, Sep 1, 2012 at 4:54 PM, Derick Rethans der...@php.net 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 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 may be changed via setDefaultPattern and
 date_default_pattern_set,
  as explained in the RFC.

 The default should most definitely not be ISO-8601 - as it's a lossy
 format.


In terms of lossy transmission/storage, what concerns in regards to the
pattern are you referring to?  ISO-8601 is only output *if* there is no
pre-set pattern provided. So in essance,



  The link to the RFC and patch are here:
  https://wiki.php.net/rfc/datetime_tostring.

  Methods Added
 
  void DateTime::setDefaultPattern(string $pattern)
  string DateTime::getDefaultPattern(void)

 This should be descriptive. You are *only* dealing with __toString here.
 Hence the method names should reflect that:

   void DateTime::setToStringFormat(string $pattern)
   string DateTime::getToStringFormat(void)


 However, I still don't believe this belongs in the class at all. It is
 rather trivial to do this in userland:

 class MyDateTime extends DateTime {
 static $format = ... some format...;
 function __toString() { return $this-format(DateTime::$format); }
 }

 There, 4 lines. And no quaralling about formats or naming.


I'm definitely not sold on any naming convention or format, and I don't see
any quarrelling going on.  The purpose of the RFC is to come up with a
solution and discuss implementation.   I don't expect any quarrels for
something this simple.

I would like this discussed.  This is a feature often brought up and
requested.  I understand that it may be difficult to come to a solution,
but let's try.



  ?php
  $date = new DateTime('2012-09-01 02:43:00');
  print_r($date);

 Should not output just:

  DateTime Object
  (
  [date] = 2012-09-01 02:43:00
  [timezone_type] = 3
  [timezone] = America/Chicago
  )

 But instead should always have the tostring pattern in there.


I agree and will update.



 Also, have you checked whether it shows up when you run serialize on it?


The patch I originally wrote did implement wakeup and set state.
 Unfortunately, an accidental git checkout -- in the wrong path gave me the
distinct pleasure of rewriting this.



 cheers,
 Derick

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

[Will Fitch]

On Sat, Sep 1, 2012 at 9:54 PM, Stas Malyshev smalys...@sugarcrm.comwrote:

 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 must indicate there's actually no default pattern that is default
 for everyone. Which suggests maybe we shouldn't have default string
 conversion there?
 After all, nothing prevents one from having:

 class MyDateTime extends DateTime {
public function __toString() {
 return $this-format(/* whatever my favorite format is */);
}
 }

 I'm not sure introducing special state to DateTime for it is the best
 way to handle it. Also, most applications would have common date format
 - which means since the state is per DateTime object, they'd have to
 watch that every object produced would have this property set. I think
 it'd be easier to just use DateTime-format() - this way you know what
 is produced and it is clear for whoever is reading the code too.


Hi, Stas.  This has been on my mind as well.  I've considered that maybe an
INI wide setting would be beneficial here.  In fact, there are many places
within applications I've worked on where the format for many DateTime
objects are the same.  What are your thoughts on that?


 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

[Will Fitch]

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 64% Yes.

On Tue, Aug 28, 2012 at 4:18 AM, Pierre Joye pierre@gmail.com wrote:

 hi,

 On Tue, Aug 28, 2012 at 2:21 AM, Johannes Schlüter
 johan...@schlueters.de wrote:
  On Sun, 2012-08-26 at 21:07 +0300, Yahav Gindi Bar wrote:
  On Sun, Aug 26, 2012 at 9:00 PM, Will Fitch willfi...@php.net wrote:
 
   Maybe the simplest solution is we have a minimum participation rate
 before
   voting can be closed?
  
  Though it make sense - it's a problem, because it'll delay and reject
 some
  useful features because of requirements issue.
 
  If it is useful it should have enough supporters, else it most likely
  isn't useful. While there should be an option to actively abstain from
  voting.

 I am not sure the usefulness of this option, but it is possible to add
 a blank field ot any vote.

 If the idea is to say 'I do not care enough to vote yes or no' then
 simply vote no as one obviously either did not the RFC or do not want
 it.

 But this is off topic again in this thread, what's about creating a
 separate one if you feel like we need to refine this process?

 Cheers,
 --
 Pierre

 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

[Will Fitch]

You're right.  My apologies.

On Tue, Aug 28, 2012 at 1:11 PM, Andrew Faulds a...@ajf.me 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 64%
 Yes.

 Sorry, disregard that previous email. I didn't look at the vote before
 sending it.

 If you look at the vote at the moment, it's 11 to 4, or 11/15. That is
 above 2/3rds, which is 10/15.


 --
 Andrew Faulds
 http://ajf.me/

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

[Will Fitch]

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 smalys...@sugarcrm.comwrote:

 Hi!

  Only people with a VCS account (or voting group) can vote.

 OK, I stand corrected then, but participation rate is still awfully low.
 We can't talk about consensus when everything is decided on one vote.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

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

[Will Fitch]

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 yohg...@ohgaki.net wrote:

 Hi,

 2012/8/21 Herman Radtke hermanrad...@gmail.com:
  May be we should have something like
 
  
   array_delete_if($array, function($v, $k=null) { if ($v == 300) return
   true; })
  
   So array_filter?
 
  I'll use it or like for deleting, but the point of this thread is
  intuitive function for deleting element(s)
 
  array_delete($array, $value|callable)
 
  would be nicer for users, perhaps.
 
 
  You are basically asking to alias array_filter with array_delete. That
 is
  a very slippery slope. I think array_filter is very a very obvious
 choice to
  remove something from an array. The filter function/method is common in
  functional languages (and functional frameworks like Underscore).
 
  These are things developers just need to learn as part of development.
  Really, this is entire thread should be on stack overflow, not internals.

 I guess you haven't read later post.

 You've also made a novice mistake.
 array_filter() DO NOT delete elements, but creates new array.
 array_delete() is another form of array_walk(), not array_filter().
 See my posts.

 Having a API for dedicated task is good thing.
 Who would argue array_pop()/array_push() isn't needed?

 Regards,

 --
 Yasuo Ohgaki
 yohg...@ohgaki.net

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

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

[Will Fitch]

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 smalys...@sugarcrm.comwrote:

 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 whose value
 is 42 without knowing the variable name. Array is a container indexed by
 keys, not values. So if you've got just a value, there's no way to know
 if it's in the container at all, and if it is, where it is, except for
 going through all the values and checking if any of them is equal to
 what you nedd.

  Just look at the number of horrible ways people solve this obvious
 problem:

 I see:
 if(($key = array_search($del_val, $messages)) !== false) {
 unset($messages[$key]);
 }

 Nothing horrible here.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

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

[Will Fitch]

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 glo...@nebm.ist.utl.ptwrote:

 https://wiki.php.net/rfc/**incompat_ctxhttps://wiki.php.net/rfc/incompat_ctx

 An RFC for deprecating and removing $this from incompatible context.

 Comments are welcome.

 --
 Gustavo Lopes

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

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

[Will Fitch]

On Mon, Jul 30, 2012 at 3:11 PM, Todd Ruth tr...@proposaltech.com 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 just a user, but I'd like to beg that the feature not be
 removed, at least not without having an ini setting for at least
 a couple of years.  As the RFC states, This feature can, however,
 be used  to implement trait-like behavior, and I'm sure someone
 somewhere did such a thing.  I know in our company's code, such
 uses were frequent.  I believe they are still common.  Refactoring
 often doesn't fit the schedule.  I doubt we're unusual in allowing
 classes to do more than they should instead of separating code
 off into a trait or making other high level changes.  Note that
 traits have only been available since March 1, 2012 (php 5.4.0).


 I don't think axing register globals is very relevant.  Perhaps after
 traits have been available for 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 We've made huge
 BC breaks before.  That doesn't make it less painful.


Software evolution at this level will always have some aches and pains for
someone.  This is a feature that has been discouraged (E_STRICT) for a very
long time, and, as pointed out in the RFC, is around only to be compatible
with PHP 4.  This should've been nixed with the death of PHP 4 IMO.  If we
waited around for everyone to update their codebase before
deprecating/removing features, it would never happen.  The point of
deprecation is to give a final warning that a feature is going to be
removed in a future release.  This should be your company's indication to
make the necessary changes.

That said, the length of deprecation is up in the air.  I'm not sure that
removing in the release immediately after deprecation is the right route,
but deprecating this in the next release *should* happen.


 Off-topic, but to show a potentially higher priority...
 If you want to get rid of class related WTF, please put
 get_class() back to the way it used to be.  Right now, calling
 get_class() with a variable that is null is the same as calling
 get_class with no arguments.  I can imagine why that might be
 convenient for the implementation, but it is terribly confusing.

 Thanks for listening.

 - Todd


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

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

[Will Fitch]

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 $_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 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
   register_globals.
   
  
  
  Given that all three of $_GET $_POST and $_COOKIE are equally suspect
  from a security POV, and you shouldn't really *care* which way the
  client delivered the value, or at least not rely on it for anything
  useful, I've never understood the resistance to using $_REQUEST.
  
  Yes, GET should be idempotent, but there are many APIs and functions
  in a large app that are idempotent by nature, and having a REST that
  just doesn't care how the data comes in allows the consumer of the
  service to use whatever they prefer.
  
  If your entire REST service is read-only, such as an RSS feed, why not
  allow GET or POST (or, silly as it may be COOKIE) and just use
  $_REQUEST.
  
 
 
 Because GET and POST are not even remotely the same thing and treating 
 them as completely interchangeable is a bug in the first place. It is 
 in fact legal to have both in the same request. Then what do you do?
 
 

The same thing that is done with $_REQUEST and virtually any other global 
parameter-based framework.  You set your data priority.  If you need to access 
them separately, then you can do that.  What Richard said wasn't that they are 
identical, rather they should be treated with equal security measures.  The 
idea that POST is more secure than GET is ridiculous.  That said, you *should* 
care about which section of the request header you submit the data (e.g. you 
obviously don't want your login form to submit via GET).
 
 The idea of having a real request object in PHP is a good one; however, 
 a superglobal is not it. Making it a superglobal eliminates the value 
 of a real request object, namely that you can encapsulate it, override 
 it locally, pass it around, mock it for testing, etc. in a safe fashion. 
 A superglobal request object is a complete waste of time.
 
 There are a number of existing request object libraries out there 
 already. PECL HTTP in C, both Zend and Symfony2 have their versions, 
 etc. Drupal is in the process of moving to Symfony's. Any PHP-core 
 request object (which in general I will agree is a good thing, and 
 something sorely missing in the language today) should be based on one 
 of those, where there's already existing work done to work out the 
 kinks. Simply throwing $_GET onto a property of a superglobal object 
 does not accomplish anything useful.
 
 

As you noted, every framework has their own version of request/response 
objects.  This is the job of a framework and not the core language.   
 
 --Larry Garfield
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 

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

[Will Fitch]

Personally, I don't like this.  We already have $_REQUEST which can accommodate 
GET, POST, and COOKIE. I believe it should be up to framework/API authors to 
implement there own methodologies behind accessing this data.  Additional 
functionality such as setting filters would be a part of that 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 feeler on something.
 Currently we have several input parameter objects, chief among them
 $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
 of them are arrays and legacy code sometimes writes to them. Locking
 them as read only objects would cause a major BC break.
 
 What if instead we had an Object called $_PARAMETERS which holds the
 read only copies of this data. In addition, this would be the first
 superglobal object, able to perform some filtering of inputs. Basic
 idea..
 
 $_PARAMETERS
 -get
 -post
 -cookie
 -headers (The client http headers)
 
 All of these would be array objects, and all would be read only and
 have these methods and properties
 
 -filtered: Copy of the array according to the current set filters of
 the object.
 -setFilters(): Sets the filters of the input, an array with constant
 values for the allowed types.
 
 And I'll stop there. The basic idea, to add a read only input hive
 with some basic object functionality for filtering.
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 

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

[Will Fitch]

On Wednesday, February 22, 2012 at 10: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 $_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 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
 register_globals.
 
 

$_REQUEST isn't dangerous - the programmer using it is.   
 
 I'm not recommending $_REQUEST.
 
 $_PARAMETERS is an object, not an array. I suppose if treated like an
 array it could behave like request - but I deeply dislike that idea
 because it is a repeat of the mistake of $_REQUEST.
 
 

You're going to have a hard time selling this.  Adding an object to global 
scope by adding yet another super global is a mess.  You'd have a much easier 
time selling a SPL class which handles this functionality.  Or, even better, 
write this *in* PHP.  There wouldn't be a substantial performance improvement, 
and you wouldn't be forcing ideologies on other developers.  If you're 
wondering what I mean by this, your suggestion of setFilters would require an 
interface that defines the behavior intended for filtering content.  On top of 
this, you'd need to add getFilters, getFilter, removeFilters, removeFilter and 
addFilter to name a few.  All of this can (and should IMO) be done within PHP.
 
 To get a value from a get request I'd use $_PARAMETERS-get['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.  
The information you provided is just not enough.  
 
 
 
 On Wed, Feb 22, 2012 at 10:03 AM, Will Fitch will.fi...@gmail.com 
 (mailto:will.fi...@gmail.com) wrote:
  Personally, I don't like this.  We already have $_REQUEST which can
  accommodate GET, POST, and COOKIE. I believe it should be up to
  framework/API authors to implement there own methodologies behind accessing
  this data.  Additional functionality such as setting filters would be a part
  of that 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 feeler on something.
  Currently we have several input parameter objects, chief among them
  $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All
  of them are arrays and legacy code sometimes writes to them. Locking
  them as read only objects would cause a major BC break.
  
  What if instead we had an Object called $_PARAMETERS which holds the
  read only copies of this data. In addition, this would be the first
  superglobal object, able to perform some filtering of inputs. Basic
  idea..
  
  $_PARAMETERS
  -get
  -post
  -cookie
  -headers (The client http headers)
  
  All of these would be array objects, and all would be read only and
  have these methods and properties
  
  -filtered: Copy of the array according to the current set filters of
  the object.
  -setFilters(): Sets the filters of the input, an array with constant
  values for the allowed types.
  
  And I'll stop there. The basic idea, to add a read only input hive
  with some basic object functionality for filtering.
  
  --
  PHP Internals - PHP Runtime Development Mailing List
  To unsubscribe, visit: http://www.php.net/unsub.php
  
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 

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

[Will Fitch]

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 familiar to most developers.



 public function ($a, $b) returns nullable ClassName {

 }


 Or any other variation that puts the return type after the function name
 /paramter list. Some advantages:

 1) The function keyword is dealt with gracefully


The function keyword is already being discussed as being removed for
methods.  See https://wiki.php.net/rfc/optional-t-function



 2) I imagine it would be easier for the parser


Your proposed alternative would create an additional token returns and
add the additional step to check *after* the method/function has been
declared.  The syntax in the RFC just replaces an existing token, making
the check almost nothing, in terms of additional checks.




 3) it is easier to extend that syntax if ever in the future the
 functionality expanded


How does it make it easier to extend?  Let's say we add exception labeling:

public function something() returns SomeClass throws Exception

To me, this looks much more elegant:

public SomeClass something() throws Exception

This requires much less typing and would match the already defined
syntactical approach by Java.



 4) most importantly is it is very readable when scanning code. When a
 programmer is scanning code
 usually the function is most important and not the return type. Imagine
 some frameworks, like Magento, with the proposed syntax
 and the readability issues it will provide with 50 methods in a class with
 variable length return type declarations:


 public nullable Mage_Core_Model_Core_Resource_Collection_Abstract
 example() {

 }


 Versus:

 public example() returns nullable
 Mage_Core_Model_Core_Resource_Collection_Abstract {

 }


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'm open to modifying the patch to do so.
 However, adding an additional token will cause additional time.





-- 
Will Fitch
Zend Certified Engineer
931.205.8242

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

[Will Fitch]

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 considered in 
that category.

On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote:

 I think annotations is a completely different topic to be discussed
 separately. First the type hinting for variables and return values has to be
 supported by the language, including hinting for primitive types. If and
 when this is done, then, if annotations are supported natively, maybe these
 2 can be combined. 
 
 
 
 Dmitri Snytkine
 Web Developer
 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: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com] 
 Sent: Tuesday, December 27, 2011 11:12 AM
 To: PHP Developers Mailing 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 time.
 
 To be honest I don't know even if that's possible. So, it's just a thought.
 
 2011/12/24 Will Fitch will.fi...@gmail.com
 
 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
 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
 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 will.fi...@gmail.com 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 return null. I'd like to know what others think. I see Stas'
 argument that you'll still have to check, but I'm not so sure that is
 such a bad thing.
 
 I see it as a very bad thing, for two reasons:
 
 1) Unconditionally allowing null to be returned takes away an element
 of
 control. You can't get away from error handling, but it's nice to be
 able
 to handle errors how you want. Having nulls thrown at you at any time
 means you have to be ready to handle them at any time, rather than
 handling them off in a separate area where you have taken the time to
 properly prepare for them. This makes for a lot more redundant code
 unrelated to the core functionality of the code, and it kills much of
 the
 utility of things like fluent interfaces.
 
 2) With type-hinted parameters, the choice has already been made not to
 allow null values at any time. Rather, the programmer must explicitly
 allow them in the parameter declaration. Doing the same with return
 types
 would provide an important bit of consistency.
 
 
 Regards,
 
 Bob
 
 --
 Robert E. Williams, Jr.
 Associate Vice President of Software Development
 Newtek Businesss Services, Inc. -- The Small Business Authority
 https://www.newtekreferrals.com/rewjr
 http://www.thesba.com/
 
 
 
 
 
 
 
 Notice: This communication, including attachments, may contain
 information that is confidential. It constitutes non-public information
 intended to be conveyed only to the designated recipient(s). If the reader
 or recipient of this communication is not the intended recipient, an
 employee or agent of the intended recipient who is responsible for
 delivering it to the intended recipient, or if you believe that you have
 received this communication in error, please notify the sender immediately
 by return e-mail and promptly delete this e-mail, including attachments
 without reading or saving them in any manner. The unauthorized use,
 dissemination, distribution, or reproduction of this e-mail, including
 attachments, is prohibited and may be unlawful. If you have received this
 email in error, please notify us immediately by e-mail or telephone and
 delete the e-mail and the attachments (if any).
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

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 is to match the state of 
parameter type hints.

On Dec 27, 2011, at 11:19 AM, Dmitri Snytkine wrote:

 I think annotations is a completely different topic to be discussed
 separately. First the type hinting for variables and return values has to be
 supported by the language, including hinting for primitive types. If and
 when this is done, then, if annotations are supported natively, maybe these
 2 can be combined. 
 
 
 
 Dmitri Snytkine
 Web Developer
 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: Jonathan Garcia Lima [mailto:jonathangl...@gmail.com] 
 Sent: Tuesday, December 27, 2011 11:12 AM
 To: PHP Developers Mailing 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 time.
 
 To be honest I don't know even if that's possible. So, it's just a thought.
 
 2011/12/24 Will Fitch will.fi...@gmail.com
 
 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
 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
 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 will.fi...@gmail.com 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 return null. I'd like to know what others think. I see Stas'
 argument that you'll still have to check, but I'm not so sure that is
 such a bad thing.
 
 I see it as a very bad thing, for two reasons:
 
 1) Unconditionally allowing null to be returned takes away an element
 of
 control. You can't get away from error handling, but it's nice to be
 able
 to handle errors how you want. Having nulls thrown at you at any time
 means you have to be ready to handle them at any time, rather than
 handling them off in a separate area where you have taken the time to
 properly prepare for them. This makes for a lot more redundant code
 unrelated to the core functionality of the code, and it kills much of
 the
 utility of things like fluent interfaces.
 
 2) With type-hinted parameters, the choice has already been made not to
 allow null values at any time. Rather, the programmer must explicitly
 allow them in the parameter declaration. Doing the same with return
 types
 would provide an important bit of consistency.
 
 
 Regards,
 
 Bob
 
 --
 Robert E. Williams, Jr.
 Associate Vice President of Software Development
 Newtek Businesss Services, Inc. -- The Small Business Authority
 https://www.newtekreferrals.com/rewjr
 http://www.thesba.com/
 
 
 
 
 
 
 
 Notice: This communication, including attachments, may contain
 information that is confidential. It constitutes non-public information
 intended to be conveyed only to the designated recipient(s). If the reader
 or recipient of this communication is not the intended recipient, an
 employee or agent of the intended recipient who is responsible for
 delivering it to the intended recipient, or if you believe that you have
 received this communication in error, please notify the sender immediately
 by return e-mail and promptly delete this e-mail, including attachments
 without reading or saving them in any manner. The unauthorized use,
 dissemination, distribution, or reproduction of this e-mail, including
 attachments, is prohibited and may be unlawful. If you have received this
 email in error, please notify us immediately by e-mail or telephone and
 delete the e-mail and the attachments (if any).
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

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 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 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 will.fi...@gmail.com 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 return null. I'd like to know what others think. I see Stas'
 argument that you'll still have to check, but I'm not so sure that is
 such a bad thing.
 
 I see it as a very bad thing, for two reasons:
 
 1) Unconditionally allowing null to be returned takes away an element of
 control. You can't get away from error handling, but it's nice to be able
 to handle errors how you want. Having nulls thrown at you at any time
 means you have to be ready to handle them at any time, rather than
 handling them off in a separate area where you have taken the time to
 properly prepare for them. This makes for a lot more redundant code
 unrelated to the core functionality of the code, and it kills much of the
 utility of things like fluent interfaces.
 
 2) With type-hinted parameters, the choice has already been made not to
 allow null values at any time. Rather, the programmer must explicitly
 allow them in the parameter declaration. Doing the same with return types
 would provide an important bit of consistency.
 
 
 Regards,
 
 Bob
 
 --
 Robert E. Williams, Jr.
 Associate Vice President of Software Development
 Newtek Businesss Services, Inc. -- The Small Business Authority
 https://www.newtekreferrals.com/rewjr
 http://www.thesba.com/
 
 
 
 
 
 
 
 Notice: This communication, including attachments, may contain information 
 that is confidential. It constitutes non-public information intended to be 
 conveyed only to the designated recipient(s). If the reader or recipient of 
 this communication is not the intended recipient, an employee or agent of 
 the intended recipient who is responsible for delivering it to the intended 
 recipient, or if you believe that you have received this communication in 
 error, please notify the sender immediately by return e-mail and promptly 
 delete this e-mail, including attachments without reading or saving them in 
 any manner. The unauthorized use, dissemination, distribution, or 
 reproduction of this e-mail, including attachments, is prohibited and may be 
 unlawful. If you have received this email in error, please notify us 
 immediately by e-mail or telephone and delete the e-mail and the attachments 
 (if any).
 


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

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

[Will Fitch]

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 be returned,
regardless of the situation, or using another token to identify that
it could return null. I'd like to know what others think. I see Stas'
argument that you'll still have to check, but I'm not so sure that is
such a bad thing.

Sent from my iPad

On Dec 23, 2011, at 3:07 PM, Clint M Priest cpri...@zerocue.com wrote:

 That syntax is pretty readable, would there be alternatives such as:

 function foo() returns Class3, array or null {
 }

 -Original Message-
 From: Dmitri Snytkine [mailto:dsnytk...@ultralogistics.com]
 Sent: Friday, December 23, 2011 7:48 AM
 To: 'Ángel González'; 'PHP Developers Mailing List'
 Subject: RE: [PHP-DEV] Return Type Hinting for Methods RFC

 Is this how it's done in Scala?

 Dmitri Snytkine
 Web Developer
 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: Ángel González [mailto:keis...@gmail.com]
 Sent: Thursday, December 22, 2011 7:45 PM
 To: PHP Developers Mailing List
 Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC

 (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
 unconvinced on which)

 What about this?

 function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
 }


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


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


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

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

[Will Fitch]

On Dec 23, 2011, at 4:29 PM, Robert Williams wrote:

 On 12/23/11 13:34, Will Fitch will.fi...@gmail.com 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 return null. I'd like to know what others think. I see Stas'
 argument that you'll still have to check, but I'm not so sure that is
 such a bad thing.
 
 I see it as a very bad thing, for two reasons:
 
 1) Unconditionally allowing null to be returned takes away an element of
 control. You can't get away from error handling, but it's nice to be able
 to handle errors how you want. Having nulls thrown at you at any time
 means you have to be ready to handle them at any time, rather than
 handling them off in a separate area where you have taken the time to
 properly prepare for them. This makes for a lot more redundant code
 unrelated to the core functionality of the code, and it kills much of the
 utility of things like fluent interfaces.

Many have expressed this same concern.  I'm going to update the patch and RFC 
to reflect this.  If we decide to add a marker/token to indicate allowing null, 
we will decide after discussing this change.  Baby steps

 
 2) With type-hinted parameters, the choice has already been made not to
 allow null values at any time. Rather, the programmer must explicitly
 allow them in the parameter declaration. Doing the same with return types
 would provide an important bit of consistency.
 
 
 Regards,
 
 Bob
 
 --
 Robert E. Williams, Jr.
 Associate Vice President of Software Development
 Newtek Businesss Services, Inc. -- The Small Business Authority
 https://www.newtekreferrals.com/rewjr
 http://www.thesba.com/
 
 
 
 
 
 
 
 Notice: This communication, including attachments, may contain information 
 that is confidential. It constitutes non-public information intended to be 
 conveyed only to the designated recipient(s). If the reader or recipient of 
 this communication is not the intended recipient, an employee or agent of the 
 intended recipient who is responsible for delivering it to the intended 
 recipient, or if you believe that you have received this communication in 
 error, please notify the sender immediately by return e-mail and promptly 
 delete this e-mail, including attachments without reading or saving them in 
 any manner. The unauthorized use, dissemination, distribution, or 
 reproduction of this e-mail, including attachments, is prohibited and may be 
 unlawful. If you have received this email in error, please notify us 
 immediately by e-mail or telephone and delete the e-mail and the attachments 
 (if any).


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

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

[Will Fitch]

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 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 will.fi...@gmail.com 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 return null. I'd like to know what others think. I see Stas'
 argument that you'll still have to check, but I'm not so sure that is
 such a bad thing.
 
 I see it as a very bad thing, for two reasons:
 
 1) Unconditionally allowing null to be returned takes away an element of
 control. You can't get away from error handling, but it's nice to be able
 to handle errors how you want. Having nulls thrown at you at any time
 means you have to be ready to handle them at any time, rather than
 handling them off in a separate area where you have taken the time to
 properly prepare for them. This makes for a lot more redundant code
 unrelated to the core functionality of the code, and it kills much of the
 utility of things like fluent interfaces.
 
 2) With type-hinted parameters, the choice has already been made not to
 allow null values at any time. Rather, the programmer must explicitly
 allow them in the parameter declaration. Doing the same with return types
 would provide an important bit of consistency.
 
 
 Regards,
 
 Bob
 
 --
 Robert E. Williams, Jr.
 Associate Vice President of Software Development
 Newtek Businesss Services, Inc. -- The Small Business Authority
 https://www.newtekreferrals.com/rewjr
 http://www.thesba.com/
 
 
 
 
 
 
 
 Notice: This communication, including attachments, may contain information 
 that is confidential. It constitutes non-public information intended to be 
 conveyed only to the designated recipient(s). If the reader or recipient of 
 this communication is not the intended recipient, an employee or agent of the 
 intended recipient who is responsible for delivering it to the intended 
 recipient, or if you believe that you have received this communication in 
 error, please notify the sender immediately by return e-mail and promptly 
 delete this e-mail, including attachments without reading or saving them in 
 any manner. The unauthorized use, dissemination, distribution, or 
 reproduction of this e-mail, including attachments, is prohibited and may be 
 unlawful. If you have received this email in error, please notify us 
 immediately by e-mail or telephone and delete the e-mail and the attachments 
 (if any).


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

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

[Will Fitch]

Sent from my iPhone

On Dec 23, 2011, at 6:32 PM, André Rømcke a...@ez.no wrote:

2011/12/23 John Crenshaw johncrens...@priacta.com

  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 noting that it *may* return null?
 
  Example: Return null at will
 
  public ArrayIterator getIterator()
  {
 // something happened, will return null
 return null;
  }
 
  Example: Return only if identified as such
 
  public ArrayIterator? getIterator()
  {
  return null;
  }

 I hate the syntax in the second example (using ?).



It looks strange, but easy to get used to. Two examples from C#:

public decimal? Grade { get; set; }

public NullableSystem.DateTime Time { get; set; }



If it is decided that we continue down the road of limiting nullable
returns, and want to add an indicator, what about something like this:

public nullable ArrayIterator getIterator()

If the nullable token isn't declared, it can't return null.




 IMO allowing null should be the default unless specifically disallowed.


I disagree for the reasons mentioned by for instance Robert.
Type hints should be strict/explicit or not done at all.

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

[Will Fitch]

In the interest of providing options for an ability to mark a method as 
returning null, I have added a new patch here: 
http://www.willfitch.com/php/nullable.patch  

This includes a new token T_NULLABLE.  Here are a few examples:

// This is allowed
private nullable ArrayIterator getIterator()
{
   return null;
}

// This throws an E_RECOVERABLE_ERROR
private ArrayIterator getIterator()
{
return null;
}

The token/identifier can certainly change, but I want to provide the most 
options for the best solution.


On Dec 23, 2011, at 6:31 PM, André Rømcke wrote:

 2011/12/23 John Crenshaw johncrens...@priacta.com
  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 noting that it *may* return null?
 
  Example: Return null at will
 
  public ArrayIterator getIterator()
  {
 // something happened, will return null
 return null;
  }
 
  Example: Return only if identified as such
 
  public ArrayIterator? getIterator()
  {
  return null;
  }
 
 I hate the syntax in the second example (using ?).
 
 
 It looks strange, but easy to get used to. Two examples from C#:
 
 
 public decimal? Grade { get; set; }
 
 public NullableSystem.DateTime Time { get; set; }
 
  
 
 IMO allowing null should be the default unless specifically disallowed.
 
 I disagree for the reasons mentioned by for instance Robert.
 Type hints should be strict/explicit or not done at all.

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

[Will Fitch]

On Dec 22, 2011, at 9:09 AM, Dmitri Snytkine wrote:

 The return type hinting is probably the biggest thing happening in php in a
 long time.
 Is this too good to be true?

Hopefully not.  We will see when the voting commences. :)

 
 With return type hinting I can see a huge improvenets in php IDEs in
 spotting errors. Also it will be much easier to auto generate wsdl files
 when return types are known to a compiler.
 These are just to name a couple of important benefits that can come out of
 it.
 
 What I don't see is any discussion of being able to declare the type of
 variable, you now, like in Java.
 ie: 
 private \ArrayObject $customers;

Type hinting is relatively new to PHP, so we need to take careful steps in 
moving forward.  With the introduction of parameter type hinting 5.0, and 
return type hinting following its lead, we will set ourselves up for a good 
base for a type hinting API and structure.  That said, PHP is not Java, and 
type hinting in PHP is very different.  It is, in fact, type *hinting*.  This 
is a runtime feature.  Only interface validation is verified at compile time, 
so we have to consider performance vs. feature in these cases.

 
 Also, is there an implicit void return type?

The following types are allowed for both parameters and method returns:

- Callable
- Object (class name)
- Array

By not declaring a type hint with a parameter, it is considered mixed.  With 
method returns, simply using the keyword function as you have been will 
signify mixed as well.

 
 I hope that declaring types of variables will be added too because without
 it, this feature is not all that useful. 
 
 Dmitri Snytkine
 Web Developer
 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:will.fi...@gmail.com] 
 Sent: Wednesday, December 21, 2011 5:29 PM
 To: Pierre Joye
 Cc: Nikita Popov; PHP Developers Mailing List
 Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
 
 Hi Pierre and Nikita,
 
 I have added callable to the patch and updated the RFC entry to reflect the
 changes. Please verify and let me know if you have any issues.
 
 On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:
 
 hi Will,
 
 You should add it now, while 5.4 final is not released 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 will.fi...@gmail.com 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 parameter type hinting, and can easily be
 added.
 
 On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:
 
 Hi Will!
 
 One random thought I had while reading the RFC is: What about the
 newly introduced callable typehint? Is this missing by intention? I
 could well imagine so (because it's hard to check what scope
 callability should be checked on), but wanted to be sure on that.
 
 Nikita
 
 On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com
 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
 the current HEAD.
 
 There is an older entry still in existence, but this patch is
 syntactically different.  The older entry is located at
 https://wiki.php.net/rfc/typechecking and is bundled with parameter,
 scalars, etc.
 
 If possible, can someone promote this to the Under Discussion
 category within https://wiki.php.net/rfc?
 
 -- Will
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 -- 
 Pierre
 
 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

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

[Will Fitch]

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 \Customer getCustomer()

 
 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 slighly harder time of detecting a mismatch.

This isn't a compile time feature.  The validation happens at runtime.  Many 
IDEs actually use PHP executables to detect syntax errors only.  In terms of 
code flow, they'll still need to rely on Doc comments and lexical analysis.

 
 I really believe that variable type hinting should be worked on at the same
 time or even before the type hinting for returns.
 
 But it's not up to me of cause, just adding my thoughts to the discussion of
 this topic. I think this is a very important topic by the way.
 
 Dmitri Snytkine
 Web Developer
 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: Nikita Popov [mailto:nikita@googlemail.com] 
 Sent: Thursday, December 22, 2011 10:02 AM
 To: Dmitri Snytkine
 Cc: Alain Williams; internals@lists.php.net
 Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
 
 Could we maybe keep this discussion contained to return value type
 hints please? Optional variable type hinting is a completely different
 topic that would require a separate RFC and implementation. If you are
 interested in this you can propose a RFC for this.
 
 Nikita
 
 On Thu, Dec 22, 2011 at 3:59 PM, Dmitri Snytkine
 dsnytk...@ultralogistics.com wrote:
 I never said to make it mandatory, only to make it available. Just like
 the
 type hinting of function call is optional but not mandatory, which is a
 big
 advantage over Java in my opinion.
 After all, if you make return type hinting mandatory, it would break 100%
 of
 all existing php scripts.
 
 To clarify I am asking to make type hinting for variable declaration an
 available option.
 
 Dmitri Snytkine
 Web Developer
 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: Alain Williams [mailto:a...@phcomp.co.uk]
 Sent: Thursday, December 22, 2011 9:52 AM
 To: internals@lists.php.net
 Subject: Re: [PHP-DEV] Return Type Hinting for Methods RFC
 
 On Thu, Dec 22, 2011 at 03:33:40PM +0100, Sebastian Krebs wrote:
 
 private \ArrayObject $customers;
 
 
 Once more Why is PHP not Java?
 
 That comment confuses matters. People use PHP for all sorts of reasons,
 the
 desire to tighten up in some places, on some occasions, should not be
 treated
 with derision.
 
 Tighter declarations, or any declarations at all, would not be mandatory.
 It
 would
 be something that some projects might want to do. It would be nice if this
 could be
 done on a module but module basis ... eg the implementors of a class
 library
 might
 want to be really strict while allowing the class users to not be strict.
 
 Just because Java has a feature that you appear to not like, does not mean
 that
 others might not want it in some circumstances.
 
 --
 Alain Williams
 Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
 Lecturer.
 +44 (0) 787 668 0256  http://www.phcomp.co.uk/
 Parliament Hill Computers Ltd. Registration Information:
 http://www.phcomp.co.uk/contact.php
 #include std_disclaimer.h
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

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 slighly harder time of detecting a mismatch.
 
 The compiler does not even try to detect a mismatch; type hinting is
 taken into account at run-time only. So whenever this function executes,
 if it tries to return a value that is not a \Customer, a run-time error
 will be reported.

The only exception is implementing an interface that defines a returned type 
hint.  This is detected at compile time but only to the point that the 
implemented method prototype is the same type hint.  If it is not, an 
E_COMPILE_ERROR is raised.  The runtime error raised is an E_RECOVERABLE_ERROR.

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


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

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

[Will Fitch]

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 ($tester) { return 5; }
 return 99;
 }
 
 Return type hinting needs to be aligned with parameter type hinting, and
 as has been pointed out many times on this list, type hinting for
 interchangable scalar types is a really bad idea. It will push all type
 checking up to the caller of the underlying functions/methods. PHP is
 primarily a Web scripting language and the Web isn't typed. Having stuff
 like this break:

Have you taken a look at the RFC and/or patch?  This functionality is exactly 
aligned with parameter type hinting.  Only classes, arrays and callables are 
allowed types.   I agree 100% on scalars.

 
 if(age_check($_POST['age'])) { do_stuff(); }
 
 because the author of the age_check() function added an int type hint
 just doesn't make any sense. It would cause everyone to have to start
 casting things everywhere, just in case. eg.
 
 if(age_check((int)$_POST['age'])) { do_stuff(); }
 
 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. This puts the effort in the
 correct place and doesn't encourage this type of coding.

It absolutely isn't.  I'm also against the class casting RFC which would, in 
effect, do this very same thing.

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


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

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

[Will Fitch]

On Dec 22, 2011, at 1:50 PM, Paul Dragoonis wrote:

 On Thu, Dec 22, 2011 at 6:41 PM, Rasmus Lerdorf ras...@lerdorf.com 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 ($tester) { return 5; }
 return 99;
 }
 
 Return type hinting needs to be aligned with parameter type hinting, and
 as has been pointed out many times on this list, type hinting for
 interchangable scalar types is a really bad idea. It will push all type
 checking up to the caller of the underlying functions/methods. PHP is
 primarily a Web scripting language and the Web isn't typed. Having stuff
 like this break:
 
 if(age_check($_POST['age'])) { do_stuff(); }
 
 because the author of the age_check() function added an int type hint
 just doesn't make any sense. It would cause everyone to have to start
 casting things everywhere, just in case. eg.
 
 if(age_check((int)$_POST['age'])) { do_stuff(); }
 
 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. This puts the effort in the
 correct place and doesn't encourage this type of coding.
 
 
 I agree with Rasmus.
 
 My opinion:
 This isn't java, if you want a strongly typed language, there's plenty out
 there, but we're not looking to make PHP more like Java and the rest, if it
 was like Java then it wouldn't have been successful for the web as it
 is/was. PHP is popular because of the way it was from the start, if php
 _needed_ scalar typehints then it wouldn't have been as popular.
 
 There is need for the existing Typehinting for class types so you don't
 need to have is_a() function calls. This makes sense.
 
 Scalars are VERY powerful in PHP, because of its loose typed nature. Having
 a 'numeric' typehint makes sense, because it can be an int, float, or
 string. Adding typehints like 'int' and 'float' will only piss people off,
 and make PHP more difficult and less fluent to code in.
 
 Lets not go there please..

I agree.  Let's not go there.  I'd like to focus more on the actual RFC at 
hand.  It makes sense to discuss potentials and what if's, but type hinting 
scalars has been shot down many times - the most important being that it would 
destroy the loosely typed nature of scalars.

 
 Thanks,
 Paul Dragoonis.
 
 
 
 
 -Rasmus
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 


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

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

[Will Fitch]

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. This puts the effort in the
 correct place and doesn't encourage this type of coding.
 
 Putting such code into the correct place does not change the problem
 that you and Stas describe
 
 function age_check($age)
 {
 if (!is_int($age)) {
 throw new InvalidArgumentException;
 }
 }
 
 With the above code, the caller needs to cast and the writer of the
 age_check() function has to copy/paste/adapt these checks to all the
 correct places ...

There are cases, such as the one you pointed out, that requires type casting.  
We're just trying to point out a situation where, if scalars were allowed to be 
typed, would produce code littered with type casts.  Point taken though.

 
 I am not advocating type hints for scalars, I am just saying that this
 argument is not really a good one against it.
 
 -- 
 Sebastian BergmannCo-Founder and Principal Consultant
 http://sebastian-bergmann.de/   http://thePHP.cc/
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

Re: [PHP-DEV] Scalar Type Hint

[Will Fitch]

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 showing that the 
discussion is dead.  After 6 months, feel free to bring it up again.

On Dec 22, 2011, at 2:52 PM, Christian Kaps wrote:

 Hi internals,
 
 someone in the Return Type Hinting for Methods RFC thread had the idea of a 
 numeric type hint. I will capture this idea and propose a scalar type 
 hint. I understand the problem of the current discussion about scalar type 
 hints(int, float, string, double, ...). But there should be a possibility to 
 define a scalar type hint to restrict arguments to scalar types.
 
 function setName(scalar $name) {}
 
 class Foo {
public function __toString() {}
 }
 
 setName(1) // pass
 setName(true) //pass
 setName('Christian') // pass
 setName(new Foo) // pass
 setName(array()) //fail
 setName(new stdClass) //fail
 
 Why this isn't possible?
 
 Christian
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

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 runtime will check and enforce that for me.  When
 
 I'm sorry but I don't see how what you describe is good. You stopped worrying 
 about checking inside the function, but unless you have started checking 
 outside the function you've just made your code less robust that it was 
 before. While in the case of strict class typing the case of mismatched 
 classes is so rare that occasional failure is easily identifiable, you didn't 
 really improve your code. I agree that it makes you type less - but the cost 
 of it is your application also does less - you don't have a capability of 
 gracefully handling a problem any longer. Again, with object strict typing, 
 this might be OK since failures are very rare and usually a result of obvious 
 mistakes caught early in testing - but if they are not, you didn't really 
 gain much.

I wouldn't be opposed to moving from raising an E_RECOVERABLE_ERROR to some 
type of exception.  In fact, I'd support it (in a discussion over that RFC).  
Your argument of not checkout outside the function is exactly why many are 
against type hinting scalars to begin with.  A generic scalar keyword being 
added would help some, but only protect against objects, resources and arrays.

 -- 
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

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 ras...@lerdorf.com 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 ($tester) { return 5; }
 return 99;
 }
 
 Return type hinting needs to be aligned with parameter type hinting, 
 and as has been pointed out many times on this list, type hinting for 
 interchangable scalar types is a really bad idea. It will push all 
 type checking up to the caller of the underlying functions/methods. 
 PHP is primarily a Web scripting language and the Web isn't typed. 
 Having stuff like this break:
 
 if(age_check($_POST['age'])) { do_stuff(); }
 
 because the author of the age_check() function added an int type hint 
 just doesn't make any sense. It would cause everyone to have to start 
 casting things everywhere, just in case. eg.
 
 if(age_check((int)$_POST['age'])) { do_stuff(); }
 
 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. This puts the effort 
 in the correct place and doesn't encourage this type of coding.
 
 
 I agree with Rasmus.
 
 My opinion:
 This isn't java, if you want a strongly typed language, there's plenty out 
 there, but we're not looking to make PHP more like Java and the rest, if it 
 was like Java then it wouldn't have been successful for the web as it 
 is/was. PHP is popular because of the way it was from the start, if php 
 _needed_ scalar typehints then it wouldn't have been as popular.
 
 There is need for the existing Typehinting for class types so you don't need 
 to have is_a() function calls. This makes sense.
 
 Scalars are VERY powerful in PHP, because of its loose typed nature. Having 
 a 'numeric' typehint makes sense, because it can be an int, float, or 
 string. Adding typehints like 'int' and 'float' will only piss people off, 
 and make PHP more difficult and less fluent to code in.
 
 Lets not go there please..
 
 Thanks,
 Paul Dragoonis.
 
 
 
 
 -Rasmus
 
 --
 PHP Internals - PHP Runtime Development Mailing List To unsubscribe, 
 visit: http://www.php.net/unsub.php
 
 
 
 Slightly off topic, but I keep seeing this problem:
 
 PHP is not language X is a terrible argument. This is a smokescreen 
 designed to insult the other person, belittle their concerns, and avoid 
 discussing the real issue. This doesn't advance the discussion at all. 
 
 Concluding that PHP is popular because you can't {insert requested feature 
 here} is also ridiculous but it happens again and again whenever language 
 features are discussed. PHP is popular independent of not {insert missing 
 feature here}. It is popular because it was on the scene early, has good 
 server support, and does an excellent job of making it trivial to handle most 
 simple web requests.
 
 Nobody wants to be told to shut up and go use language X.
 
 Let's discuss things on their own merits.
 
 /rant
 
 John Crenshaw
 Priacta, Inc.
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

Sent from my iPad
On Dec 22, 2011, at 5:51 PM, Ángel González keis...@gmail.com 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 functions?

Right now, it's only available for methods. Personally, I'm not a fan
of return types for functions. Adding this for functions in its form
today will also introduce shift/reduce issues.


 In functional programming, it is common to return nullable types:
 returns an instance of class Foo or null, an array or false, etc.

 This is supported in normal arguments with the = null hint, and I
 think there should be something equivalent for return types.
 Does the proposed implementation allow null everywhere? (there's an
 example of returning null from a return hint of array)
 That seems wrong to me. Unless there's a way to make it strict (eg.
 array! for only arrays).

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.



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

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

[Will Fitch]

On Dec 22, 2011, at 6:28 PM, Stas Malyshev smalys...@sugarcrm.com 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 everything is OK and false if not is a very 
 common pattern.
 Also, you understand that always allowing null means that this construct:

 $foo = $this-returnsFoo();
 $foo-fooMethod();

 is no longer safe as you wanted it to be when you made returnsFoo use strict 
 typing? You'd have to check $foo anyway.

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.

The point isn't to restrict a type hint to always be returned. The
goal is to guarantee that if a value is returned, it will be of type
X. In the event it is inappropriate to return the value back, would
you rather receive null or a bogus class instance, empty array or a
random function name back? Because that's what will happen. It will
become the workaround for not being able to return null.


 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

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

[Will Fitch]

Sent from my iPhone

On Dec 22, 2011, at 7:14 PM, Stas Malyshev smalys...@sugarcrm.com 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 am not suggesting that. I'm just pointing out the problems with the 
 concept of strict typing in PHP and this particular instance of it. One of 
 them is that many functions do not actually return one type but multiple 
 types depending on the result. It is a very common pattern.

And in those cases, they would continue to use the keyword function
and be considered unknown as they are today.


 BTW, which languages you are talking about? PHP peers - Python, Ruby, Perl, 
 Javascript (to some measure), etc. don't have typing as far as I know. 
 Comparing PHP to statically compiled strictly typed languages does not seem 
 very useful to me. So could you clarify what do you mean?

Not seem useful? Then during the discussions of parameter type
hinting, which language did you compare it to? What about abstracts
and interfaces?

I don't compare PHP to ruby, python or JavaScript. Do I suggest
features that I find useful in other languages like C# or Java or even
in any of the ones you listed? Absolutely.

Limiting yourself to comparing features only found in interpreted
languages is a very narrowed scope. Yes, return type validation does
add overhead, just as parameters do (arguably more). But it is a
feature that is very valuable to many. Those who wish not to use it
can continue to do so.

Don't forget that while return checks are runtime, interface
definition and implementations are compile time.


 The point isn't to restrict a type hint to always be returned. The
 goal is to guarantee that if a value is returned, it will be of type
 X. In the event it is inappropriate to return the value back, would

 All functions in PHP return values, so it is not possible that no value would 
 be returned (yes, if you don't return anything it actually will return null). 
 So ensuring something is an object of type X prevents you from returning 
 anything else, false/null included. If you make exceptions for null, then why 
 not for false? If for false, then why not for true? Etc.

Because null is a standard already set by parameter type hints. I do
not want to sway away from that as it works well.  It is common for
null values to be considered nothing, which is exactly what will be
returned if the specified hint isn't. All or nothing.

 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

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

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

[Will Fitch]

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 feature in a general-purpose language that 
 would be used by literally millions.

The feature isn't designed around only those who use it.  In fact, as per the 
RFC, the keyword function will be used to serve as a mixed return type.  
There are cases where I don't want to type hint my return value from a method 
and will continue to use this.  All scalar values will be forced to use this 
way anyway.  Namespaces, interfaces, abstracts, closures, traits. the list 
goes on with features that were built to give developers additional tools to 
use.  Are any of them required to use? No.  It's general purpose - just like 
the feature offered here.  How many features are built into PHP that are meant 
to force a user to use it, or even break BC?  Why would you suggest this is 
doing any different?  Can you provide an example where this feature is doing 
that?

 
 I don't compare PHP to ruby, python or JavaScript. Do I suggest
 features that I find useful in other languages like C# or Java or even
 in any of the ones you listed? Absolutely.
 
 C# and Java, again, are fully statically typed compiled languages. PHP is 
 not. That means that the benefits of strict type system that are available to 
 programmers in C# or Java will not be available to PHP programmers, while the 
 downsides of it (and inflexibility that such system leads to) will still be 
 there and will actually be multiplied by the fact that you wouldn't know 
 about the problem with your typing system until your application starts 
 crashing.

Are you saying parameter type hinting isn't in PHP?  

 
 add overhead, just as parameters do (arguably more). But it is a
 feature that is very valuable to many. Those who wish not to use it
 can continue to do so.
 
 Sorry, again, don't use it is not a valid response for a core feature in a 
 widely used language. It would be OK for a PECL module - if you don't like 
 mongoDB, don't use it, nobody objects to having mongodb extension because it 
 is not fit for some scenarios. However, designing core language features that 
 change the nature of the language - making it from non-typed to strictly 
 typed - have bigger requirements. You can not just not use core feature - 
 because others will be using it and you'd have to leave with it and interface 
 with their code.

Sorry, again, look at what I said above.  Namespaces, interfaces, abstracts, 
closures, traits, parameter type hints, even classes are core features that 
users aren't forced to use.  Please tell me what makes them different.  It is 
an optional feature - just like all those I listed.  If others are using it, 
that's the point.  Can you walk into existing code that you must interface with 
today that has a type hinted parameter and decide not to use it?  No.  Why?  
Because the company/developer who developed that solution made the decision 
that it was a feature they found useful.  What you're suggesting is that we 
design features around those who do not want to use it. 

 
 Don't forget that while return checks are runtime, interface
 definition and implementations are compile time.
 
 Nothing is compile time in PHP, PHP has no compile time (at least if we don't 
 consider projects like HipHop, which is totally irrelevant here) like C# or 
 Java does. That's not how PHP code works. In C# and Java, you can take the 
 code and know in advance the type of any piece of data in any place (maybe 
 not precisely but at least base type). In PHP, you can not.

So Java's bytecode, which requires a VM (interpreter), isn't comparable to 
PHP's compile?  Are you saying compile is only when code is converted into 
machine code?  Moving PHP code through a lexical analyzer, syntax parser, 
intermediate code generator/opcode isn't a form of compilation?  Considering 
the verification of interfaces is done during the syntax parser, in a file 
called zend_compile.c, before the code is actually executed, I'm pretty 
comfortable calling this transformation compiled.


 
 Because null is a standard already set by parameter type hints. I do
  not want to sway away from that as it works well.  It is common for
 
 I'm not sure what you're talking about as a standard. Yes, input parameters 
 strict typing allows nulls because it was another frequently used scenario 
 that strict typing does not support.  Fortunately, it could be fit into 
 default value syntax, even though it doesn't really means that (so we 
 actually have a syntax that means two different things now, not a great 
 idea). But with return types and value strict types (which would inevitably 
 be asked for next) it wouldn't be that easy. There's no syntax for default 
 return value and the case of returning false - 

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

[Will Fitch]

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 keis...@gmail.com 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 functions?
 Right now, it's only available for methods. Personally, I'm not a fan
 of return types for functions. Adding this for functions in its form
 today will also introduce shift/reduce issues.
 Yes, it's much easier for the parser for methods with explicit
 visibility (note that public is optional).
 I'm ok on requiring the public for methods with a return hint, but if
 methods can get return hints,
 normal functions must, too.
 
 If it's hard with your proposed syntax, it should be discarded and a
 better one developed.
 Else we would end up with different syntaxes for return hints depending
 on the kind of function.

It's not a matter of being difficult.  I can see your argument, however.

 
 
 For instance, the return hint could go at the end of the prototype:
 
 function foo (Class1 $a, Class2 $b) = Class3 {
   return new Class3($a, $b);
 }
 
 (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 unconvinced on which)

Let me see what can be done without doing too much to the definitions.  I like 
the idea of not making function required.

 
 
 In functional programming, it is common to return nullable types:
 returns an instance of class Foo or null, an array or false, etc.
 
 This is supported in normal arguments with the = null hint, and I
 think there should be something equivalent for return types.
 Does the proposed implementation allow null everywhere? (there's an
 example of returning null from a return hint of array)
 That seems wrong to me. Unless there's a way to make it strict (eg.
 array! for only arrays).
 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.
 I disagree with you, but Stas already provided a compelling case.
 


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

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

[Will Fitch]

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 smalys...@sugarcrm.com wrote:
 In PHP, returning object if everything is OK and false if not is a very 
 common pattern.
 Also, you understand that always allowing null means that this construct:
 
 $foo = $this-returnsFoo();
 $foo-fooMethod();
 
 is no longer safe as you wanted it to be when you made returnsFoo use 
 strict typing? You'd have to check $foo anyway.
 Are you suggesting not allowing null to be returned, or provide an
 indicator within the syntax that it may return null? 
 It should be possible to allow it. Either with a generic syntax for
 allowing
 many types of return types or through a specific one (eg. in C# a ?
 marks an internal type as nullable: int? )

You can return null from methods.  Parameters and variables are nullable.  I'm 
not against appending an indicator as to whether null may be returned, but that 
would need to be a general consensus, I think.

I would like other opinions on this...

 
 PHP would be the
 first language I'm aware of that would do so in either case.
 It already barfs at you if you pass null to a parameter expecting a
 given class
 (though you can allow it).
 
 
 The point isn't to restrict a type hint to always be returned. The
 goal is to guarantee that if a value is returned, it will be of type
 X. In the event it is inappropriate to return the value back, would
 you rather receive null or a bogus class instance, empty array or a
 random function name back? Because that's what will happen. It will
 become the workaround for not being able to return null.
 As it would support both ways, it's up to the framework to choose if
 they want to
 return null or a fake-class interface.

Yes, it would.  But providing the option of null would be a good incentive not 
to do that.  At the end of the day, you're giving a set of tools to someone.  
If they choose to use it in a way that's less efficient, or wrong in other's 
eyes, that's their choice.

 
 


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

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

[Will Fitch]

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 unconvinced on which)
 
 What about this?
 
 function foo (Class1 $a, Class2 $b) return Class3 {
/* Do something */
return new Class3($a, $b);
 }
 
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

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, will return null
   return null;
}

Example: Return only if identified as such

public ArrayIterator? getIterator()
{
return null;
}





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

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

[Will Fitch]

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 parameter type hinting, and can easily be added.

On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:

 Hi Will!
 
 One random thought I had while reading the RFC is: What about the
 newly introduced callable typehint? Is this missing by intention? I
 could well imagine so (because it's hard to check what scope
 callability should be checked on), but wanted to be sure on that.
 
 Nikita
 
 On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com 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 
 the current HEAD.
 
 There is an older entry still in existence, but this patch is syntactically 
 different.  The older entry is located at 
 https://wiki.php.net/rfc/typechecking and is bundled with parameter, 
 scalars, etc.
 
 If possible, can someone promote this to the Under Discussion category 
 within https://wiki.php.net/rfc?
 
 -- Will
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 


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

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

[Will Fitch]

Will add tonight and generate a new patch.  


On Dec 21, 2011, at 2:33 PM, Pierre Joye wrote:

 hi Will,
 
 You should add it now, while 5.4 final is not released 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 will.fi...@gmail.com 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 parameter type hinting, and can easily be 
 added.
 
 On Dec 21, 2011, at 12:17 PM, Nikita Popov wrote:
 
 Hi Will!
 
 One random thought I had while reading the RFC is: What about the
 newly introduced callable typehint? Is this missing by intention? I
 could well imagine so (because it's hard to check what scope
 callability should be checked on), but wanted to be sure on that.
 
 Nikita
 
 On Wed, Dec 21, 2011 at 3:09 AM, Will Fitch will.fi...@gmail.com 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 the current HEAD.
 
 There is an older entry still in existence, but this patch is 
 syntactically different.  The older entry is located at 
 https://wiki.php.net/rfc/typechecking and is bundled with parameter, 
 scalars, etc.
 
 If possible, can someone promote this to the Under Discussion category 
 within https://wiki.php.net/rfc?
 
 -- Will
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 
 
 
 
 -- 
 Pierre
 
 @pierrejoye | http://blog.thepimp.net | http://www.libgd.org


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