Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100358
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.15.15 as permitted sender)
To: internals@lists.php.net
References: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
Message-ID: <4d88678e-47e0-0f83-813c-c76daa8df003@gmx.de>
Date: Mon, 4 Sep 2017 00:27:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: 8bit
Subject: Re: [VOTE] UUID
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 02.09.2017 at 09:01, Fleshgrinder wrote:

> I just started the voting for the inclusion of a UUID value object in
> PHP's core, targeting PHP 7.3. I wanted to start earlier, but was sick
> the whole week.
> 
> The voting is open starting now and until September 16. (2 weeks).

IMHO, the RFC misses its own point.  The introduction claims that
uniqid() is insufficient, and that UUIDs are much more appropriate.  I
fully agree.  However, instead of providing a single function to replace
uniqid() it offers a full blown class which even includes *parsing* of
UUIDs.  The RFC furthermore claims:

| A programming language’s standard module should provide the most basic
| and repeating building blocks, to ensure that developers can achieve
| things fast without much hassle.

I fully agree, but I don't see that *parsing* of UUIDs is such a most
basic building block, and even most of the rest of the proposed UUID
class doesn't appear to fit that category.

With regard to type-safety (which is probably the point of parse()):
having type-safe UUIDs is only a fraction of one percent of what is
occasionally needed in applications – do we really want to add thousands
of classes to ext/standard?

-- 
Christoph M. Becker