Readit News logoReadit News
elnatro · 2 years ago
I envy the fast development cycles the PHP language developer team is doing. From five years until now, I’d say PHP has had a completely overhaul since the time I stopped web development.
pirate787 · 2 years ago
As a long-time PHP developer, its way too fast. We're forced to constantly upgrade for features that don't really matter for most uses, but aren't backwards compatible.
Implicated · 2 years ago
As someone maintaining multiple 10+ year old PHP applications - after the migration to 7 things have been super easy/simple. Especially if you get Rector [0] involved.

[0] https://github.com/rectorphp/rector

NorwegianDude · 2 years ago
What do you mean? Backwards compatibility in PHP is amazing. I have several large projects that I've been working on for 15+ years, and upgrading to newer PHP versions has been a dream.

What kind of things are you having problems with in regards to backwards compatibility?

nolok · 2 years ago
You're going to need to give exemples here. Upgrading has been super simple.

The one time you actually may have had to work on things was with PHP 7, but that's because they finally removed things that had been deprecated for years, some for over a decade, and all of them were security risks or massive code smell anyway.

The one thing with PHP 8 was the removal of dynamic propery, and again that's a massive code smell that was holding the language back. Any code still using it when PHP 8 released was either written over a decade ago, or something that has way more issues than that with upgrading.

kyriakos · 2 years ago
Never had trouble upgrading since jumping from 5.6 to 7.1. Changes are minor and can mostly be automated via tooling.
TekMol · 2 years ago
I am surprised there is no discussion in the PHP community to introduce a module system.

The current solution for code reuse (use longer class names to avoid clashes, we help you with syntactic sugar called "namespaces") is the wrong approach imo.

supriyo-biswas · 2 years ago
Composer autoloading and the PSR-4 naming convention works just fine, since you have to separate the class names with some kind of information about the developer, followed by the name of the class. Java uses a similar naming scheme too ("org.apache.commons.SomeClass" etc.) though autoloading is specific to PHP.

I'm curious as to why you consider autoloading over PSR-4 namespaces as insufficient.

Cyykratahk · 2 years ago
Version conflicts on shared transitive dependencies is a real problem, to the point that there are tools available to library authors that allow them to rename their dependencies to be under their own namespace to avoid collisions.

If two packages I require depend on incompatible versions of some third package, there aren't any easy ways for me to resolve it.

This problem exists because of the global nature of PHP namespaces.

morelisp · 2 years ago
To begin with, the fact the "module" system is tied to classes is a horrible design flaw. (Also in Java, but Java leans into it - PHP still has functions and lots of stuff is clearer as functions.)
onlypositive · 2 years ago
"works just fine" - obviously never watched xdebug shart the bed while composer tries to version match phpunit.

A module system and less reliance on PSR the better. Why exactly does PSR still exist?

TekMol · 2 years ago
Working around underlying problems with tools and conventions is something that is fine when you get paid for your time.

As a maker, I prefer a clean stack. So that its complexity does not slow me down. Workarounds make development slower and slower, the more it becomes a giant hairball of workarounds and workarounds around workarounds.

In Python and JavaScript, I don't need those workarounds. Would be awesome if PHP catches up.

throw_m239339 · 2 years ago
> The current solution for code reuse (use longer class names to avoid clashes, we help you with syntactic sugar called "namespaces") is the wrong approach imo.

You can in theory create modules with require.

module.php

    <?php 
    return (function(){
        $foo = function(){echo "hello from PHP";};
        return [
          "greet"=>$foo
        ];
    })();
script.php

    <?php 
    $module = require('./module.php');
    $module["greet"]();
But PHP namespaces and autoloading via composer ARE the community accepted way to handle namespacing. The ecosystem is so large developers aren't going to move to a different module system at that point. Especially when composer is the defacto package manager for PHP.

tored · 2 years ago
Namespaces and modules are orthogonal, you can support both like Typescript.

Your solution works, but unfortunately not something that has any community support. I proposed something similar a year ago but use classes instead because classes seems to be the internal building block in PHP.

For both our solutions is would relatively easy to add a shim to older PHP versions.

module.php

    <?php
    
    return new class {
        public const MY_CONST = 47;

        private const MY_PRIVATE_CONST = 127;
    
        // with PHP 8.1 you also have readonly properties
        public string $myPublic = 'foo';
    
        private int $myPrivate = 17;
    
        public function helloWorld(string $name): void
        {
            echo "Hello, World {$name}!";
        }
    };
main.php

    <?php
    
    final class ModuleException extends Exception {
    }
    
    function module(string $name): object
    {
        static $modules = [];
    
        if (isset($modules[$name])) {
            return $modules[$name];
        }
    
        try {
            $module = @require $name;
        } catch (Error $error) {
            throw new ModuleException("No such module {$name}", 0, $error);
        }
    
        if (!is_object($module)) {
            throw new ModuleException("Module {$name} is not an object");
        }
    
        $modules[$name] = $module;
        return $module;
    }
    
    $my = module('module.php');
    $my->helloWorld('Module system');
    
    $other = module('module.php');
    assert($my === $other);
    
https://news.ycombinator.com/item?id=30242974

n0n0n4t0r · 2 years ago
Honestly, as a PHP développer, the node's module system impress me A LOT. I went on several projects that had not kept their dependencies on the "edge version". For some, it was more than a year of work just to be able to move from php7 to php8.

PHP dependencies are so intertwined that for projects that abuse and use more than a reasonable amount (aka their ability to invest time keeping them and the code using it up to date) the update process can become a nightmare of complexity.

Node's module system let you move each dependency at it's own pace. This is such a breath!

The problem is that when you only know of the solution of your ecosystem, it's hard to see the added value you miss out.

tored · 2 years ago
My recommendation for every PHP projects that uses external libraries is to use your own wrapper function/class to minimize contamination of the project.

If you use a framework then try to write all your own code outside of the framework and pass in all needed framework data as arguments to your own classes/functions.

pictur · 2 years ago
PHP language and ecosystem as clear as possible. no piss races. there are no marketing developers. or they probably exist but i don't see them.
kyriakos · 2 years ago
They are some actually, but specifically for Laravel, rather than php.
9dev · 2 years ago
Yep. Laravel drags the otherwise great php ecosystem into the dirt. Other than that, there’s heaps of great libraries and quality development out there.
PUSH_AX · 2 years ago
Equally, would you say there is much innovation in the PHP world? Legit question as a non php dev.
iKevinShah · 2 years ago
There's some innovation - YES but a lot of "catching up" with other languages.

All in all, super positive.

Deleted Comment