Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119836 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 93737 invoked from network); 8 Apr 2023 20:28:43 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 8 Apr 2023 20:28:43 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 358BE1804D4 for ; Sat, 8 Apr 2023 13:28:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 8 Apr 2023 13:28:41 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id h198so7986666ybg.12 for ; Sat, 08 Apr 2023 13:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680985721; x=1683577721; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6tA2E/CM4SZ5lK4IUmnGLyTsp2tXLz7t2S2fD1c39GQ=; b=SiWyUPRx+yIPv70uJQOGxuRebHLM1HNVROas+k9OGyVsJytxURbNLZTRInjt3hBKRF nAD7VRLcYYM3dLNvASYHrHfPHMl5+lWlMBxcRhuyO3f1gG7vHq+Tvsfiylko3JehPMDO u347zqJYdjY35h1/yj+qcF4hpasPu8sas7Yka/zGwQkkJ/npjy4C11y/M8JX5CDODBcg hjhbXre1F4+7gOXQy6M+M/nIJ0y4bxHEw1Vu/hl4FxnR3F5lOt0IGVRcsHrJqdLasMdT DAbQLjT+3LUiOWk1ZoN6hH9E2VQ39SQPYB8VEruPc1BVrcErjuhcFLl1D786w9oDkeZc qH4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680985721; x=1683577721; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6tA2E/CM4SZ5lK4IUmnGLyTsp2tXLz7t2S2fD1c39GQ=; b=VHGtqrVRsSc4knRJUFB9C5kcYTcafVK4tsSYs0nhPV21v0VKHw3xwuIOTRF4ztRXy/ TrkrJR2omaD2MF5wlh60eBR63NXCH+nIfAh2rjQRDlkmAqiPUk8WRw4f1O0qM0gIorpq dzOmKkPZxnYFztNrsDDtHJ4Cx+bq0SWLAMi1mpMrqEFRNzXa1ZWX747fqWeFX5IqcoxT oqsBNDg/ID67w+LwGoo+2XmS9/YP6pHCtO14k8W7jHybyl3A6Ow2f8zn2mRDm2PfZAcX GZL/SchtHyOfNS+9I5lPa8PS5lcKE2biMAjjZ4z6Ycz9Ea6IRo9bNG7m9KpPyM6L9Qm3 vaQQ== X-Gm-Message-State: AAQBX9dTX0SmprX+msP5OpGEdz8g37vMwhZTMDqzIl6iUXjMYY6RRsxL x1ZT49zITVD7IVVH7bdPwHzPkFeSbHbTH4mwY0nJNdaA X-Google-Smtp-Source: AKy350ZKJtV7NrAE21NBHl23YH/cakGG3N6WEK5bxmzHEAkdrJUC1rm/RfYi84Q88K6nNiguHMmlFgXSv7qsRJmfeQ8= X-Received: by 2002:a25:73ca:0:b0:b8e:dadc:a081 with SMTP id o193-20020a2573ca000000b00b8edadca081mr1096143ybc.5.1680985720754; Sat, 08 Apr 2023 13:28:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Sat, 8 Apr 2023 21:28:29 +0100 Message-ID: To: Stephan Soller Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="000000000000c2198705f8d8fc12" Subject: Re: [PHP-DEV] Future stability of PHP? From: tekiela246@gmail.com (Kamil Tekiela) --000000000000c2198705f8d8fc12 Content-Type: text/plain; charset="UTF-8" Hi Stephan, Generally, PHP tries to keep as much backwards compatibility as possible. Breaking changes are limited to minimum and done in the least obstructive way possible. When a deprecation is introduced, you have at least 3 years to update your code. But PHP also tries to move forward and the language improves each year. We certainly got many more features than breaking changes. Just think of match expression, enums, attributes, constructor property promotion, new Random API, readonly properties/classes, first-class callable, consistent errors and many more. The biggest improvement in PHP 7 and 8 was a comprehensive type system. It's something that you don't have to use, therefore doesn't affect existing code much, but makes development so much more enjoyable and less bug-prone. I know I have discovered many bugs because of migration to PHP 8 and introduction of proper types. And this is the direction PHP is going in. The language is still dynamic and allows for taking the easy route, but new features focus on reducing bugs by making the code's behaviour less surprising. If you try to adhere to clean code principles, upgrades should not be a huge problem. Use static analysis and good tests. Learn and follow clean code practices, e.g. SOLID. Use abstraction in your code; it's better to change code only in one place than change it across hundreds of files. Some tools help you during migrations, such as Rector and phpcbf, but to use them proficiently, your code needs to be free from surprises. Dynamic properties are a very good example of surprising behaviour. By looking at the definition of the class, you don't know what properties it has. If any of the methods use undefined properties, both you and static analysers will be surprised by this. There are certain things you should avoid in your code like fire. Not because they might be removed from the language, but because they make your code unclean and cause bugs. Here is my list: - Arrays. Yes, they are a major feature of the language but also a major pain in the... Use proper data structures, which may use arrays internally, but don't use bare arrays in your code. Value objects and DTOs are invaluable. - Isset and empty. They are sometimes necessary and sometimes they are the easiest choice, but they hide so many bugs. Every time you use any of them, it should raise an immediate red flag. - References. I don't understand why the language still has this feature. Hack got rid of it and that was a very smart decision. You don't need references. Use them almost never. - Globals and superglobals. This should not need explaining. Pretty much in every language, these are pure evil. They make changes to the code an experience similar to disarming a bomb. It's tempting to use $_GET, $_POST, $_REQUEST anywhere in your code, but if you want to avoid bugs and surprises, you'd better stay away from it. There should probably be at most one place in every project where these are used. - extract() and compact(), and variable variables. These should only be used in a very tightly controlled scope, and even then, their usage can be contested. Ideally, variable variables should not exist in the language; we have arrays after all. - Sanitizing filters. Sanitization is too ambiguous term to be useful. What you should be using is validation and formatting. Validate your inputs to make sure they are the type/value you expect. Format the output so that it can't break the context it is in. - Loose comparison. I have liked that about PHP in the past, but in recent years I became a strong supporter of strict comparison. Why? Because "0" == false. Forbid using loose comparison in your coding standard and forget that it exists. Don't let the language make a fool out of you. You are the developer and you know what type you expect. Following these guidelines will not only help you avoid bugs in your code but also will make the upgrade process much less cumbersome. This and adhering to the strictest level of the static analysis tool of your choice is the recipe for success. Try to stay up to date with the changes. Every year when PHP releases a new version, go over the changelog and make an effort to learn and use new features. Even if your production is 3 years behind, you can try these out in your development environment. PHP will move forward and add new features, but sometimes it must also break some things to move forward. Kind Regards, Kamil Tekiela --000000000000c2198705f8d8fc12--