Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:110166 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 52762 invoked from network); 15 May 2020 13:16:01 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 May 2020 13:16:01 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 69FC5180088 for ; Fri, 15 May 2020 04:53:24 -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.5 required=5.0 tests=BAYES_05,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_FAIL,SPF_HELO_NONE 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-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 15 May 2020 04:53:23 -0700 (PDT) Received: by mail-ua1-f44.google.com with SMTP id s5so681416uad.4 for ; Fri, 15 May 2020 04:53:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=basereality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K1KGFD3Y9vgT++jBDya6ATmsPDv0vdhEBRr8MPyFLck=; b=cwk16CDNlnZfpQxT1cL4t4PK0e17j93WBi5noSYkVwvzrQaYKmnZt0ZBFXEimAZAwK p2OmGSD7hxYg/cakbemqzZ+/yZG5x4Cf/ce8U+zDnVYLu2Hn1lqvji9GrgGUzQOPamco MYjfUePlCiRmD6BIZ5MwGBTseylc2fD5OhRVcSnwgOL6AihNSPTGakdBWtZX3L2KIy6O WRO6xip1H8+djWN6wG31I2l+6881ZmCP+FLD7OZHP5LGs2MsyQTqlAqQCN9Ey3bhqP7u HM6onhiALKG48L/lgh2yJrLeW0+2XjbkWAE8NA3FcYIwUGrG0SCWLBppeFRFZQQLyVez R+Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K1KGFD3Y9vgT++jBDya6ATmsPDv0vdhEBRr8MPyFLck=; b=h5ew5CEpSYJDoISlHkkOH3I4r/cXgCHmFcBbosc4cn4FS2pUEZGZuuJke+bMJnkJVf tPsYI6DDEpK2/0/22jq89D3/x1ZHyuzxMGygXOYP1583L7NEIzRHU8iKYJKodXGU66tb bXB5QPf1/0xv5vMM3PIA+G21XzTViIup7UQjcGUUUYliNimDrZ4MeZ88Hr1HOovw1GDC EO0ef1+RaZOU0IFwdbtJB+SMoOs4xZs4hx824omOywwdfqYXi5SkZuwxAtZadVcWHMus V3IvpQEWfX3wBC7O0Vzg6wKgfpnawucDOPbPO+FRTAS7DHXqRtu+x0JzirfLhHmTMf/S ua4g== X-Gm-Message-State: AOAM530A3dZimCutLVQtmoxMg9l/Nu2YNve7I1nPls0lOuLIzuUsQgiJ vNc8RkEjCFAYxFvwPKzYw70Hwjw8cNtIhzf4pR8+C8mWaMj77A== X-Google-Smtp-Source: ABdhPJwlNdjpJ8f4+iomV3/HAxsFZB+AaJ5lMHu51DkwrFpudUspu4UESIrEeLuTF0v+lClqrKOojdZA0KP3OS7L0yc= X-Received: by 2002:ab0:15e6:: with SMTP id j35mr1018782uae.61.1589543598223; Fri, 15 May 2020 04:53:18 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Fri, 15 May 2020 12:53:07 +0100 Message-ID: To: Jakob Givoni Cc: php internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] SPL development interest From: Danack@basereality.com (Dan Ackroyd) On Thu, 14 May 2020 at 19:14, Jakob Givoni wrote: > > Hi Internals, > Hi Jakob, Obviously, all of the following is my own personal opinion, and other people may have different opinions. There are two main lessons learnt from the SPL experience. i) Some APIs need to evolve separately from the PHP release schedule*. As otherwise any mistake in the design of the API is locked in until the next minor release. ii) PHP needs a better way of installing extensions. There was a lot of work done on this in https://github.com/FriendsOfPHP/pickle but that effort seems to have been abandoned after a huge amount of work was done for it. If anyone has any info on what the problems were with the approach taken in that project, sharing that knowledge with the rest of the PHP community would be helpful in a new attempt to solve that problem. To answer your questions: > - What is the status of this extension currently? Is it being actively developed or just supported? It's pretty dead and the code is quite scary to even touch. > - Is there any interest in adding stuff here - f.ex. new classes, interfaces or traits? Absolutely no interest for me. As I said, new attempts to provide common libraries should be done separately from PHP core. Preferably in userland code where possible. > And technically, how is something like ArrayObject class implemented? And should you implement it again, would it be done the same way? The code is in: https://github.com/php/php-src/blob/d7f7080bb5b42a4dd2d08c91c02645b9d9a74a50/ext/spl/spl_array.c And a different approach should be taken. I've posted some notes of my thoughts on the individual parts of the SPL below. cheers Dan Ack ## Iterators These are quite useful, though possibly could do with a better developer experience around using them. The file related ones are best avoided though - see File Handling below. ## Datastructures People tend not to use them, but it is hard to express exactly why. It is partly due to some issues in their implementations. For example that the function [splpriorityqueue.recoverfromcorruption](https://www.php.net/manual/en/splpriorityqueue.recoverfromcorruption.php) exists is a pretty bad sign. There are a better set of datastructures available in the [Ds extension](https://github.com/php-ds/ext-ds). I think possibly it is related about the difficulty in converting from arrays to custom data structures and back again, being a not good experience. ## Exceptions The attempt has two fundamental mistakes in my opinion. First, I think all exceptions should extend a base exception that is specific to the library that the code is in. e.g. try { $image = new Imagick("foo.png"); $image->someMethodThatMightThrow(); } catch (ImagickException $e) { // This catch should be guaranteed to catch all exceptions // that could possibly be thrown by 'someMethodThatMightThrow' } Any exceptions to that rule, like a TypeError that is not caught internally and rethrown with an Imagick specific version, should be considered as a bug. Second, having a hierarchy of exceptions that builds up more specific meaning is something that has a strong aesthetic appeal to developers, but has no actual benefit. Other than extending a base exception for that library. ## File Handling There are multiple issues for them. They are not well designed classes, are kind of difficult to work with, and also some of the assumptions in them are unsafe. For example cloning a FileSystemIterator assumes that the directory has not changed: https://bugs.php.net/bug.php?id=69291 More fundamentally I think these classes are also a mistake. Here is a quote from a paper by Edsger W. Dijkstra*: > the purpose of abstracting is not to be vague, but to create > a new semantic level in which one can be absolutely precise. I think this can be turned round the other way. If an abstraction does not provide a new, more precise semantic level, then it does not provide any value. Those classes are not simpler to use than the low level unix file handling routines. And so they do not provide any value over just using the low level functions. In fact they are harmful as they hide some details that you probably want to know about. That is an opinion that I think also applies to the idea of providing an OO api to the functions for handling http requests, e.g. get_headers(). Although they could do with improvement through having less magic, and being more complete (e.g. why isn't there a get_body() function?) putting them all in an OO api seems the wrong thing to do to me. cheers Dan Ack * Edsger W. Dijkstra - https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html * PHP release schedule problem - https://github.com/Danack/RfcCodex/blob/master/rfc_attitudes.md#not-being-compatible-with-the-php-release-schedule