Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:99147 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 16747 invoked from network); 24 May 2017 15:29:42 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 May 2017 15:29:42 -0000 Authentication-Results: pb1.pair.com header.from=lists@rhsoft.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=lists@rhsoft.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain rhsoft.net designates 91.118.73.15 as permitted sender) X-PHP-List-Original-Sender: lists@rhsoft.net X-Host-Fingerprint: 91.118.73.15 mail.thelounge.net Received: from [91.118.73.15] ([91.118.73.15:32701] helo=mail.thelounge.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/6B-10292-5E6A5295 for ; Wed, 24 May 2017 11:29:41 -0400 Received: from rh.thelounge.net (Authenticated sender: h.reindl@thelounge.net) by mail.thelounge.net (THELOUNGE MTA) with ESMTPSA id 3wXxCN3m3szXMk for ; Wed, 24 May 2017 17:29:36 +0200 (CEST) To: internals@lists.php.net References: Message-ID: Date: Wed, 24 May 2017 17:29:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-CH Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] [Discussion] UUID From: lists@rhsoft.net ("lists@rhsoft.net") Am 24.05.2017 um 17:11 schrieb Levi Morrison: > On Wed, May 24, 2017 at 9:04 AM, Larry Garfield > wrote: > >> On 05/24/2017 04:31 AM, lists@rhsoft.net wrote: >>> >>> Am 24.05.2017 um 11:27 schrieb Dan Ackroyd: >>> >>>> Hey internals! >>>>> >>>>> I haven't written the RFC yet, >>>> >>>> Please don't forget to include in the RFC a justification for why this >>>> should be part of PHP core, rather than a library >>> >>> because as developer in reality you can not use and rely on features >>> which needs to install some pecl-library when it is supposed to be used on >>> typical hosting packages >> >> It doesn't have to be a PECL library. I agree that a project requiring a >> PECL library greatly limits its potential reach, but with Composer >> user-space libraries are totally easy to install. There's a nice and >> popular UUID implementation already: >> >> https://packagist.org/packages/ramsey/uuid >> >> Note: That doesn't mean adding UUID functionality to PHP core/standard lib >> is a bad idea; discussing that is fine. But the "no one will be able to >> use it otherwise" argument is substantially less compelling than it was >> even 5 years ago. >> > By the way there already is a PECL package for a UUID library: > https://pecl.php.net/package/uuid. I would like to see compelling reasons > why we shouldn't rally around that package because when you end in a library/extension for each and every trivial function your codebase becomes a mess - why not PECL i have explained before the post you quoted and why composer as it is working nwo is a no-go in the follow-up response not that i care much of *that* function but when in the future every functionality ends in pecl and/or composer, well, my list what not to touch will grow in the same speed we maintain a large codebase (250000 LOC) over 15 years and the only 3rd party library is 'phpmailer' and besides php-pecl-apcu and php-pecl-imagick on prodcution machines there are no 3rd partly librarie and won't be that soon - not interested in the mess 10 years later while currently i can deploy hundrets of instances with a self-contained deployment software using the same framework as the application and it's modules and build/test a php-build whithn a few minutes be it 7.0.x, 7.1.x, 7.2.x with every single external dependency that becomes harder