Re: [PHP-DEV] Proposal for a new basic function: str_contains
I generally like the idea, but it seems many (most?) real-world implementations actually use mb_strpos() !== false by default. https://github.com/danielstjules/Stringy/blob/df24ab62d2d8213bbbe88cc36fc35a4503b4bd7e/src/Stringy.php#L206-L215 https://github.com/illuminate/support/blob/6eff6cff19f7ad5540b9a61a9fb3612ca8218c19/Str.php#L157-L166 So there should definitely be an mb_str_contains in ext/mbstring in addition to the regular str_contains proposed here.
Re: [PHP-DEV] Build instructions for Ubuntu 18.04 (and other systems)
Not super familiar with building PHP, but this should be a reasonable starting point, tested on a fresh install of Ubuntu 18.04.3: apt install -y autoconf gcc bison re2c libxml2-dev libssl-dev libsqlite3-dev libcurl4-openssl-dev libpng-dev libwebp-dev libjpeg-dev vflib3-dev libc-client-dev libkrb5-dev libonig-dev libreadline-dev libsodium-dev libargon2-0-dev libzip-dev ./buildconf ./configure --enable-fpm --with-openssl --with-kerberos --with-imap-ssl --with-pcre-jit --with-zlib --enable-bcmath --with-curl --enable-exif --enable-ftp --enable-gd --with-webp --with-jpeg --with-freetype --with-gettext --with-imap --enable-intl --enable-mbstring --with-mysqli --enable-pcntl --with-pdo-mysql --with-readline --enable-sockets --with-sodium --with-password-argon2 --with-zip --enable-zts On 15.09.2019 20:49, Nikita Popov wrote: > Hi, > > Our build instructions in > https://github.com/php/php-src#building-php-source-code are currently a bit > bare... they show the basic "./buildconf && ./configure && make" cycle, but > everyone who actually tries this will quickly find out that there is a lot > more to building PHP... > > Every time I compile PHP on a new system, I have to go through a pretty > long cycle of ./configure --xxx, wait until there is an error, "sudo apt > install libxxx-dev" and so on. > > It would be great if someone could write up the required "apt get" and > "./configure" line to get a "reasonably large" build of PHP on a popular > Linux distro like Ubuntu 18.04, so this can be included in the README. > Something similar for MacOS would probably also be useful, where things are > even more complicated. > > Bonus points for also including how to set up MySQL and Postgres in a way > that you can run mysqli/pdo_mysql and pgsql/pdo_pgsql tests. I think I lose > a couple of hours every time I try to get this working. > > Anyone interested in doing this? > > Regards, > Nikita >
Re: [PHP-DEV] [RFC] Union Types v2
On the subject of using GitHub for this RFC: Personally, I think GitHub is a much better platform than the mailing list for this kind of discussion. Mailing list threads are just not very accessible to the average PHP user. Reading them through externals.io is an OK experience, but actually contributing is unnecessarily complicated. I'd imagine most people aren't really interested in something like the recent "Annotating internal function argument and return types" thread, but would very much like to participate in a discussion (even if it's just leaving a "+1") about something that affects their day-to-day work, like union types. Generally, I'd split things up like this: Truly internal work on PHP itself, things only people working *on* PHP (as opposed to *with* PHP) really care about -> internals. Changes affecting regular PHP users, RFCs for adding or removing features and things like that -> GitHub or some other platform where everyone can easily contribute. On 04.09.19 10:26, Nikita Popov wrote: > Hi internals, > > I'd like to start the discussion on union types again, with a new proposal: > > Pull Request: https://github.com/php/php-rfcs/pull/1 > Rendered Proposal: > https://github.com/nikic/php-rfcs/blob/union-types/rfcs/-union-types-v2.md > > As an experiment, I'm submitting this RFC as a GitHub pull request, to > evaluate whether this might be a better medium for RFC proposals in the > future. It would be great if we could keep the discussion to the GitHub > pull request for the purpose of this experiment (keep in mind that you can > also create comments on specific lines in the proposal, not just the > overall discussion thread!) Of course, you can also reply to this mail > instead. The final vote will be held in the wiki as usual. > > Relatively to the previous proposal by Bob&Levi ( > https://wiki.php.net/rfc/union_types), I think the main differences in this > proposal are: > * Updated to specify interaction with new language features, like full > variance and property types. > * Updated for the use of the ?Type syntax rather than the Type|null syntax. > * Only supports "false" as a pseudo-type, not "true". > * Slightly simplified semantics for the coercive typing mode. > > Regards, > Nikita >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
Before reading the responses to this thread, I had honestly never encountered a PHP developer who thought using uninitialized variables was fine. I knew it worked, but I always considered this to basically be the PHP equivalent of undefined behavior in C. And I don't think anyone would get mad if a new GCC version broke the way they were abusing UB. To me and to every developer I've ever known, the only difference between a notice and a warning is the severity of the error. But they're both considered errors - mistakes you made in your code that you need to fix. I'm fairly certain this is how most developers treat them in the real world. Either way, if you want a less strict language, that language already exists: It's the current version of PHP and you and everyone else who likes the way it works can keep using it. Meanwhile, I think most people currently doing serious PHP work would *love* some more strictness and I don't think keeping your old code running on a brand new version of the language is a good enough reason to keep this feature out of 8.0. What's the point of even having major releases if every potential BC break gets shot down by the same 3 people on this mailing list? As for the check engine light analogy, I guess instead of saying "this is fine", you just smash your entire dashboard with a hammer to make the problem go away. Because that's what using @ or error_reporting does. I hope this RFC passes, but I don't see any point in discussing it further here, so I'll go back to lurking now. On 29.08.2019 16:22, Zeev Suraski wrote: > > > On Thu, Aug 29, 2019 at 4:02 PM Aegir Leet via internals > mailto:internals@lists.php.net>> wrote: > > I know what the manual says about notices. But I don't agree with > interpreting "could happen in the normal course of running a > script" as "it's perfectly fine if this part of your code triggers > a notice consistently and every time it goes down this particular > code path". Rather, I've always interpreted this as "under > certain, rare, unforeseen circumstances, your code could generate > a notice here, probably because of something that is outside of > your control". > > That's how I've always treated them at least. > > > And that's entirely within your right to do so - but what the manual > says is accurate. Calling me delusional in my interpretation of it is > somewhat awkward (to put it mildly), I have a pretty good idea of why > we added the different error levels - I wrote much of it myself. > > The whole point of having notices as something that's separate from > warnings is that they have different semantics, and that semantics is > captured very accurately in the manual. They are used to mark issues > which may be problems, but may also be perfectly fine (unlike > warnings, which generally speaking mean that something bad happened, > but not bad enough to halt execution). Notices were meant to help you > implement a more strict style of coding, and they may help you catch > certain types of bugs, but you can have perfectly working, bug-free > code that generates notices. > > Regardless of the exact semantics, don't you think a program that > generates a constant stream of notices is a bit strange? That > sounds like something everyone would naturally want to avoid. You > don't drive your car with the check engine light permanently on > and say "this is fine", right? > > > Except you can purposely turn off this 'check engine' light, never to > see it again if you choose to. And that it's really not at all > similar to 'check engine', but a lot closer to 'check cleaning fluid', > or even 'clean windshield' (if cars had a dashboard light for that). > Even that is not a good analogy - as folks often actually purposely > write code that generates notices (which would be purposely hidden, > either by error_reporting setting or using @) that is 100% bug-free > and working as intended. So no, there's nothing strange about it if > you buy into that approach. If you don't (and I know you don't) - > that's absolutely fine - it's up to you. > > Zeev >
Re: [PHP-DEV] [RFC] Reclassifying engine warnings
I know what the manual says about notices. But I don't agree with interpreting "could happen in the normal course of running a script" as "it's perfectly fine if this part of your code triggers a notice consistently and every time it goes down this particular code path". Rather, I've always interpreted this as "under certain, rare, unforeseen circumstances, your code could generate a notice here, probably because of something that is outside of your control". That's how I've always treated them at least. Regardless of the exact semantics, don't you think a program that generates a constant stream of notices is a bit strange? That sounds like something everyone would naturally want to avoid. You don't drive your car with the check engine light permanently on and say "this is fine", right? On 29.08.19 14:43, Claude Pache wrote: Le 29 août 2019 à 13:33, Aegir Leet via internals mailto:internals@lists.php.net>> a écrit : I'm sorry, but if you seriously believe doing something that generates a notice (or warning, or error, ...) is not a bug - you're delusional. No, what you think is not at all how notices were designed. From the manual (https://www.php.net/errorfunc.constants): E_NOTICE — Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script. One can discuss whether unitialised variables should trigger a notice or a warning. But let us respect the semantics of the language features. —Claude
Re: [PHP-DEV] Re: [RFC] Reclassifying engine warnings
I'm sorry, but if you seriously believe doing something that generates a notice (or warning, or error, ...) is not a bug - you're delusional. That is the very definition of a bug and notices/warnings/errors etc. are the mechanism the language uses to report these bugs to the developer. If doing X has been generating a notice for 20 years, then doing X is wrong and a bug, period. Why would there even be a notice if the language itself doesn't consider what you're doing to be buggy? What is the purpose of notices then? I really don't understand how anyone could contest this. On 29.08.19 07:40, Zeev Suraski wrote: > > It's really awkward that anybody would be under the illusion that the way > the language always behaved, consistently and well-documented pretty much > from the its inception, is somehow a bug that everybody agrees on that's > just waiting for someone to come over and fix it.
