Re: [PHP-DEV] A validator module for PHP7
> On Sep 4, 2017, at 18:06, Marco Pivetta wrote: > > On Mon, Sep 4, 2017 at 8:56 PM, Crocodile wrote: > >> In most cases users would like more than just valid/invalid, i. e. which >> particular rule(s) failed and also human-readable error messages. As of >> simple validation that is almost always at hand, filter_* functions do a >> good job, although I agree that they could be better. I, for one, would >> like to see a full-featured validation as part of PHP. However, this RFC >> only looks like a slightly better version of filter_* functions, that is, >> the new module will provide almost the same functionality but with a >> different interface. I would vote against it. >> > > And also, it would need to be better than all of these to be worth writing > it in C: > > https://packagist.org/search/?q=validator And these as well: https://packagist.org/search/?q=filter (Or at least have some level of parity.) -- Paul M. Jones pmjone...@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][Discussion] Consistent callables
Sent from my iPhone > On 5 Sep 2017, at 03:05, Dan Ackroyd wrote: > > Stephen Reay wrote: >> Regarding the big change you suggest, making protected/private methods >> return false unless a new third parameter is true in is_callable(): >> I think you need to make your intention a *lot* clearer > >> On 29 May 2017 at 12:01, Rowan Collins wrote: >> Regarding is_callable, could lead to some very confusing bugs. IMO, when >> BC breaks are necessary, they should be big and obvious so people spot and >> fix them. > > > Most of the feedback I got was how modifying the existing is_callable > function was dumb, so I've updated the RFC, and dropped the idea of > modifying the existing is_callable function. > > That function will stay as it is, and will be used to determine if a > variable can be called in the current scope, through either direct > invocation or call_user_func(). > > The RFC instead now proposes a separate function of is_callable_type, > to determine if a variable can be used as callable in all scopes, and > so will pass the callable type check for parameters and return types. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > Hi Dan, I appreciate that you've listened to our feedback! As a userland-only dev I'm not really familiar with the trade offs/gotchas inherent to how parameters are handled in the core. Could you/someone explain/identify why a new function is better than converting the `$syntaxonly` bool parameter into a bitmask of CALLABLE_* constants, which treats Boolean true as CALLABLE_SYNTAXONLY for bc purposes? Cheers Stephen Sent from my iPhone -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A validator module for PHP7
On Mon, Sep 4, 2017 at 8:56 PM, Crocodile wrote: > In most cases users would like more than just valid/invalid, i. e. which > particular rule(s) failed and also human-readable error messages. As of > simple validation that is almost always at hand, filter_* functions do a > good job, although I agree that they could be better. I, for one, would > like to see a full-featured validation as part of PHP. However, this RFC > only looks like a slightly better version of filter_* functions, that is, > the new module will provide almost the same functionality but with a > different interface. I would vote against it. > And also, it would need to be better than all of these to be worth writing it in C: https://packagist.org/search/?q=validator Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/
Re: [PHP-DEV] [RFC][Discussion] Consistent callables
Stephen Reay wrote: > Regarding the big change you suggest, making protected/private methods return > false unless a new third parameter is true in is_callable(): > I think you need to make your intention a *lot* clearer On 29 May 2017 at 12:01, Rowan Collins wrote: > Regarding is_callable, could lead to some very confusing bugs. IMO, when > BC breaks are necessary, they should be big and obvious so people spot and > fix them. Most of the feedback I got was how modifying the existing is_callable function was dumb, so I've updated the RFC, and dropped the idea of modifying the existing is_callable function. That function will stay as it is, and will be used to determine if a variable can be called in the current scope, through either direct invocation or call_user_func(). The RFC instead now proposes a separate function of is_callable_type, to determine if a variable can be used as callable in all scopes, and so will pass the callable type check for parameters and return types. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A validator module for PHP7
In most cases users would like more than just valid/invalid, i. e. which particular rule(s) failed and also human-readable error messages. As of simple validation that is almost always at hand, filter_* functions do a good job, although I agree that they could be better. I, for one, would like to see a full-featured validation as part of PHP. However, this RFC only looks like a slightly better version of filter_* functions, that is, the new module will provide almost the same functionality but with a different interface. I would vote against it. On Mon, Sep 4, 2017 at 2:54 PM Rowan Collins wrote: > On 4 September 2017 07:33:41 BST, Yasuo Ohgaki wrote: > >Hi all, > > > >I spent a little time for a new input validation module. It's not > >totally > >new module, but is based on Filter module's validation filter > >improvement > >RFC in many ways. [1] > > Hi Yasuo, > > Thanks for tackling this. I do think the current filter module is user > unfriendly and it would be great to have something better. A couple of > quick thoughts based on your README: > > - The use of nested arrays keeps things simple in one sense, but the deep > nesting can get confusing. I wonder if a ValidationRule class would make > the distinction between parameters and references to existing rules > clearer. This would also give you a natural home for validating the > validation rules themselves (probably by throwing an exception in the > constructor). > > - A minor point, but most style guides would suggest function names should > be verbs, not adjectives, so "validate()" rather than "valid()". > > - Is there a use case for valid_id() or is it a temporary debugging thing > that won't be in the final version? > > In general, I like the idea, but would have to play around a bit to see if > it felt easy to use in real world situations. > > Regards, > > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Best regards, Victor Bolshov
Re: [PHP-DEV] [VOTE] UUID
I really, really wanted to vote yes for this as I've wanted simple UUID creation in core for a long time, but I can't agree this is the correct implementation. Something like "uuid_v4_create()" seems to make a lot more pragmatic sense and use ramsey/uuid for anything more complicated. Sorry Richard, but I'm -1 on this one. But thanks for putting in all the effort! I think another attempt with a simpler API & implementation could be a winner! :) Thanks, Sammy Kaye Powers sammyk.me On Sat, Sep 2, 2017 at 2:01 AM, Fleshgrinder wrote: > Hello Internals! > > I just started the voting for the inclusion of a UUID value object in > PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick > the whole week. > > The voting is open starting now and until September 16. (2 weeks). > > -- > Richard "Fleshgrinder" Fussenegger > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] UUID
Le 02/09/2017 à 09:01, Fleshgrinder a écrit : > Hello Internals! > > I just started the voting for the inclusion of a UUID value object in > PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick > the whole week. > > The voting is open starting now and until September 16. (2 weeks). > IMHO such a new thing should follow the common process to go to pecl first, and then merged in some new PHP version (like sodium) So -1 from me Remi signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] I this a bug in PHP 7.1.9?
On 4 September 2017 01:27:49 BST, Jefferson Gonzalez wrote:
>I upgraded my PHP version on a server from 7.0 to latest 7.1.9 and got
>this strange behaviour, did something changed on the core language or
>is
>this a bug?
>
>PHP sample code:
>--
>
>function test()
>{
> static $staticValue = test2();
>
> return $staticValue;
>}
>
>function test2()
>{
> return array();
>}
>
>print_r(test());
>
According to 3v4l.org this has never been valid: https://3v4l.org/vRaNK The
error message changed between 5.x and 7.x, but if you're already on 7.0 you
shouldn't have seen any change.
Are you sure this test case correctly represents the code you're having
problems with?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A validator module for PHP7
On 4 September 2017 07:33:41 BST, Yasuo Ohgaki wrote: >Hi all, > >I spent a little time for a new input validation module. It's not >totally >new module, but is based on Filter module's validation filter >improvement >RFC in many ways. [1] Hi Yasuo, Thanks for tackling this. I do think the current filter module is user unfriendly and it would be great to have something better. A couple of quick thoughts based on your README: - The use of nested arrays keeps things simple in one sense, but the deep nesting can get confusing. I wonder if a ValidationRule class would make the distinction between parameters and references to existing rules clearer. This would also give you a natural home for validating the validation rules themselves (probably by throwing an exception in the constructor). - A minor point, but most style guides would suggest function names should be verbs, not adjectives, so "validate()" rather than "valid()". - Is there a use case for valid_id() or is it a temporary debugging thing that won't be in the final version? In general, I like the idea, but would have to play around a bit to see if it felt easy to use in real world situations. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] com php-src: fix default args for --with-pcre-valgrind: ext/pcre/config0.m4
On 25/07/17 00:31, Christopher Jones wrote: > > > On 20/7/17 10:31 am, Anatol Belski wrote: >> Hi Chris, >> >>> -Original Message- >>> From: Christopher Jones [mailto:christopher.jo...@oracle.com] >>> Sent: Thursday, July 20, 2017 2:11 AM >>> To: Anatol Belski ; php-...@lists.php.net; Tianfang Yang >>> >>> Subject: Re: [PHP-CVS] com php-src: fix default args for >>> --with-pcre-valgrind: >>> ext/pcre/config0.m4 >>> >>> Hi Anatol, >>> >>> 7.2 & 7.3 builds now fails for me on macOS and Oracle Linux 7 with: >>> >>> checking for Valgrind headers location... configure: error: Could >>> not find >>> valgrind/memcheck.h >>> Configure failed >>> >>> Do we really want users to have to explicitly disable PCRE valgrind >>> when they are >>> using --enable-debug? >>> >> It wasn't by default in the first version, later it was suggested by >> Nikita and for debug mode certainly makes sense, as for me. The reason >> behind this option is the upgrade of the bundled PCRE, which shows a >> lot of false positives without the integrated Valgrind support. Also I >> was basing on the fact the debug mode is actually developers only, >> normal use wouldn't be affected therefore. Why would users do debug >> builds? >> >> On a dev machine Valgrind would be anyway present. For developers it's >> best to have it by default, as PCRE usage is spread around the core >> here and there. Bug fixing also does normally involve valgrind checks. >> I wouldn't see the option itself as a big question, either way. If >> many people find the default enablement unsuitable, so the behavior >> can be reversed. >> >> Regards >> >> Anatol >> > I'm not totally convinced merging debug-level arguments makes sense (why > not always enable --enable-phpdbg-debug too?) But there are more > important things to worry about, so I won't stress. > > BTW, './configure --help' prints the --with-pcre-valgrind=DIR help twice. > > Chris > Just stumbled over this one, too. I don't think it's very nice to suddenly let ./configure --enable-debug die when valgrind headders are not present, and I didn't request valgrind support in ext/pcre. Suddenly all of my travis builds failed, for no apparent reason, despite --disable-all I think it should only fail hard, if explicitly requested. -- Regards, Mike signature.asc Description: OpenPGP digital signature
RE: [PHP-DEV] [VOTE] UUID
Hey Zeev, My issue with having more core classes is just with the fact that reflection and type system are not working 1:1 like in userland. Richard fixed that in the PR with extensive testing, so that's fine. More type safety is definitely a good thing, especially when widely distributed. Passing around a UUID as a string is surely not something I'd allow in any kind of codebase I work with: it would be nuked at review. On 4 Sep 2017 11:04, "Zeev Suraski" wrote: > > -Original Message- > > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > > Sent: Sunday, September 3, 2017 10:17 AM > > To: Zeev Suraski ; internals@lists.php.net > > Subject: Re: [PHP-DEV] [VOTE] UUID > > > > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > > > > >> On 2 Sep 2017, at 13:43, Fleshgrinder wrote: > > >> The discussion was really ongoing for a long time, and actually very > > >> heated as well. It was on GitHub with lots of comments, Internals, > > >> Reddit, Twitter, ... everywhere. > > > > > > As far as I'm concerned the only relevant discussion is on internals. > It's ok to > > use other mediums (although personally I think it's not very positive) - > as long > > as they're ultimately represented on internals. > > > > > > My quick search suggested there was only roughly two days worth of > > discussion sometime in May, but it's possible I wasn't thorough in > searching. > > > > > > > What I wanted to say is that the discussion was not held secretly, on the > > contrary, it was very loud on many channels. I am not sure what you want > from > > me, because everything followed the officially prescribed procedures. > Not sure > > if I can be blamed that some people missed it. I asked for additional > feedback > > not two weeks ago before I started the vote. > > Richard, > > I'm not accusing you of anything. This is all in positive constructive > spirit, and I was the first to admit I may have missed something - and > although at this point I don't think I did, that's still a possibility. > > My point is simple - when I saw the vote, I looked for the prior > discussion on internals - which is the *only* official channel for > discussing these matters. The only discussion I could find took place > between May 24 and May 26 - i.e. well over 3 months ago. While being > intense, it raised good points which remained unanswered, and it died out > very quickly without any sort of followup. Again, I have no idea what kind > of discussion happened on reddit or IRC or other channels, but that > shouldn't matter. > > > Type safety alone is such a substantial value to me, and many others, > that it is > > reason enough to go for the class. This is also my argument in the RFC, > and I > > stand by it. > > That's great, but given that it's unprecedented, it's not a very good > argument. To quote Marco from the May discussion: > "Introducing a UUID class in PHP core as *just* a type safety wrapper > feels akin to adding an EmailAddress class to core. It's certainly not an > unreasonable way to handle things, but imho also not something that should > be in core. We should be providing the primitives based on which people can > implement whichever abstractions they prefer, in a simpler and more > flexible manner than we can achieve in extension code." > > > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > > Where's the poll / vote that most people think differently? > > > Either way, even if it can be argued that for this particular case > performance > > is a weak argument (which is debatable), it's most certainly not an > inherently > > weak argument as the current wording implies. There shouldn't be a > ratified > > PHP RFC implying that performance considerations are weak arguments, > > without clear context and explanation. > > > > The people were the ones here on Internals. Read the discussion thread > again. I > > gladly change the wording, because I also think that performance is a > valid > > argument, but did not feel like it would be accepted. Hence, the wording. > > There's a difference between certain people saying something, and 'most > people think'. There were only about 15 people that participated in this > thread, and of those, I couldn't find any that said that performance is a > weak argument. Most didn't comment about performance at all. > > I could find some that said the opposite, including Ben Ramsey: > "A UUID generator in the core will only help to improve ramsey/uuid, > providing more choice and better performance." > The 'only' there might be confusing, but it's intended in a positive way. > > I fail to see how it's possible to derive from that thread a statement > that 'performance is a weak argument', and I do think it's bad to have a > ratified php.net RFC that would make that statement as if it's an obvious > truth. > > > > Regardless of being final, they'll become a basic building block in > apps, and > > taking them away or modifying them means substantial breakage. The very > > introduction of th
RE: [PHP-DEV] [VOTE] UUID
> -Original Message- > From: Fleshgrinder [mailto:p...@fleshgrinder.com] > Sent: Sunday, September 3, 2017 10:17 AM > To: Zeev Suraski ; internals@lists.php.net > Subject: Re: [PHP-DEV] [VOTE] UUID > > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > > >> On 2 Sep 2017, at 13:43, Fleshgrinder wrote: > >> The discussion was really ongoing for a long time, and actually very > >> heated as well. It was on GitHub with lots of comments, Internals, > >> Reddit, Twitter, ... everywhere. > > > > As far as I'm concerned the only relevant discussion is on internals. It's > > ok to > use other mediums (although personally I think it's not very positive) - as > long > as they're ultimately represented on internals. > > > > My quick search suggested there was only roughly two days worth of > discussion sometime in May, but it's possible I wasn't thorough in searching. > > > > What I wanted to say is that the discussion was not held secretly, on the > contrary, it was very loud on many channels. I am not sure what you want from > me, because everything followed the officially prescribed procedures. Not sure > if I can be blamed that some people missed it. I asked for additional feedback > not two weeks ago before I started the vote. Richard, I'm not accusing you of anything. This is all in positive constructive spirit, and I was the first to admit I may have missed something - and although at this point I don't think I did, that's still a possibility. My point is simple - when I saw the vote, I looked for the prior discussion on internals - which is the *only* official channel for discussing these matters. The only discussion I could find took place between May 24 and May 26 - i.e. well over 3 months ago. While being intense, it raised good points which remained unanswered, and it died out very quickly without any sort of followup. Again, I have no idea what kind of discussion happened on reddit or IRC or other channels, but that shouldn't matter. > Type safety alone is such a substantial value to me, and many others, that it > is > reason enough to go for the class. This is also my argument in the RFC, and I > stand by it. That's great, but given that it's unprecedented, it's not a very good argument. To quote Marco from the May discussion: "Introducing a UUID class in PHP core as *just* a type safety wrapper feels akin to adding an EmailAddress class to core. It's certainly not an unreasonable way to handle things, but imho also not something that should be in core. We should be providing the primitives based on which people can implement whichever abstractions they prefer, in a simpler and more flexible manner than we can achieve in extension code." > On 9/2/2017 2:26 PM, Zeev Suraski wrote: > > Where's the poll / vote that most people think differently? > > Either way, even if it can be argued that for this particular case > > performance > is a weak argument (which is debatable), it's most certainly not an inherently > weak argument as the current wording implies. There shouldn't be a ratified > PHP RFC implying that performance considerations are weak arguments, > without clear context and explanation. > > The people were the ones here on Internals. Read the discussion thread again. > I > gladly change the wording, because I also think that performance is a valid > argument, but did not feel like it would be accepted. Hence, the wording. There's a difference between certain people saying something, and 'most people think'. There were only about 15 people that participated in this thread, and of those, I couldn't find any that said that performance is a weak argument. Most didn't comment about performance at all. I could find some that said the opposite, including Ben Ramsey: "A UUID generator in the core will only help to improve ramsey/uuid, providing more choice and better performance." The 'only' there might be confusing, but it's intended in a positive way. I fail to see how it's possible to derive from that thread a statement that 'performance is a weak argument', and I do think it's bad to have a ratified php.net RFC that would make that statement as if it's an obvious truth. > > Regardless of being final, they'll become a basic building block in apps, > > and > taking them away or modifying them means substantial breakage. The very > introduction of the class, its name (and to a lesser degree its > functionality) - are > tickets with remarkably expensive cancelation options. > > > > Zeev > > > > This is true for any addition to the language, and imho not an argument > against > the inclusion of new features. I did my very best to create a good API that is > useful in daily life. I understand that you prefer procedural programming, > and I > understand that you do not see the value of type safety. I prefer OO, like the > majority of today's PHP community, and I prefer type safety, and the > implementation is the result of these preferences. Feel fre
