Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.193 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <DM2PR02MB3023DA9D0A4E15E991BE198AC910@DM2PR02MB302.namprd02.prod.outlook.com>
References: <b92961d5-a34f-737b-896b-0d63da0f7f6b@fleshgrinder.com>
 <BY2PR02MB298C0B77E3C66533DA9F8BBAC930@BY2PR02MB298.namprd02.prod.outlook.com>
 <9f09589f-0a8e-1b8c-7b4c-b7d6899ed4ab@fleshgrinder.com> <76EE812B-922D-46B4-8525-6AFA75843816@zend.com>
 <ce7dc299-929e-ad32-1db9-ffdda06c2e4c@fleshgrinder.com> <DM2PR02MB3023DA9D0A4E15E991BE198AC910@DM2PR02MB302.namprd02.prod.outlook.com>
Date: Mon, 4 Sep 2017 11:08:47 +0200
Message-ID: <CADyq6s+AB1ubhr5CuqBw3BrC0n4G1NYY7C4ukGxPK2g-BH0wPQ@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="089e0823899478361a055859750f"
Subject: RE: [PHP-DEV] [VOTE] UUID
From: ocramius@gmail.com (Marco Pivetta)

--089e0823899478361a055859750f
Content-Type: text/plain; charset="UTF-8"

Hey Zeev,

My issue with having more core classes is just with the fact that
reflection and type system are not working 1:1 like in userland. Richard
fixed that in the PR with extensive testing, so that's fine.

More type safety is definitely a good thing, especially when widely
distributed. Passing around a UUID as a string is surely not something I'd
allow in any kind of codebase I work with: it would be nuked at review.


On 4 Sep 2017 11:04, "Zeev Suraski" <zeev@zend.com> wrote:

> > -----Original Message-----
> > From: Fleshgrinder [mailto:php@fleshgrinder.com]
> > Sent: Sunday, September 3, 2017 10:17 AM
> > To: Zeev Suraski <zeev@zend.com>; internals@lists.php.net
> > Subject: Re: [PHP-DEV] [VOTE] UUID
> >
> > On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> > >
> > >> On 2 Sep 2017, at 13:43, Fleshgrinder <php@fleshgrinder.com> wrote:
> > >> The discussion was really ongoing for a long time, and actually very
> > >> heated as well. It was on GitHub with lots of comments, Internals,
> > >> Reddit, Twitter, ... everywhere.
> > >
> > > As far as I'm concerned the only relevant discussion is on internals.
> It's ok to
> > use other mediums (although personally I think it's not very positive) -
> as long
> > as they're ultimately represented on internals.
> > >
> > > My quick search suggested there was only roughly two days worth of
> > discussion sometime in May, but it's possible I wasn't thorough in
> searching.
> > >
> >
> > What I wanted to say is that the discussion was not held secretly, on the
> > contrary, it was very loud on many channels. I am not sure what you want
> from
> > me, because everything followed the officially prescribed procedures.
> Not sure
> > if I can be blamed that some people missed it. I asked for additional
> feedback
> > not two weeks ago before I started the vote.
>
> Richard,
>
> I'm not accusing you of anything.  This is all in positive constructive
> spirit, and I was the first to admit I may have missed something - and
> although at this point I don't think I did, that's still a possibility.
>
> My point is simple - when I saw the vote, I looked for the prior
> discussion on internals - which is the *only* official channel for
> discussing these matters.  The only discussion I could find took place
> between May 24 and May 26 - i.e. well over 3 months ago.  While being
> intense, it raised good points which remained unanswered, and it died out
> very quickly without any sort of followup.  Again, I have no idea what kind
> of discussion happened on reddit or IRC or other channels, but that
> shouldn't matter.
>
> > Type safety alone is such a substantial value to me, and many others,
> that it is
> > reason enough to go for the class. This is also my argument in the RFC,
> and I
> > stand by it.
>
> That's great, but given that it's unprecedented, it's not a very good
> argument.  To quote Marco from the May discussion:
> "Introducing a UUID class in PHP core as *just* a type safety wrapper
> feels akin to adding an EmailAddress class to core. It's certainly not an
> unreasonable way to handle things, but imho also not something that should
> be in core. We should be providing the primitives based on which people can
> implement whichever abstractions they prefer, in a simpler and more
> flexible manner than we can achieve in extension code."
>
> > On 9/2/2017 2:26 PM, Zeev Suraski wrote:
> > > Where's the poll / vote that most people think differently?
> > > Either way, even if it can be argued that for this particular case
> performance
> > is a weak argument (which is debatable), it's most certainly not an
> inherently
> > weak argument as the current wording implies.  There shouldn't be a
> ratified
> > PHP RFC implying that performance considerations are weak arguments,
> > without clear context and explanation.
> >
> > The people were the ones here on Internals. Read the discussion thread
> again. I
> > gladly change the wording, because I also think that performance is a
> valid
> > argument, but did not feel like it would be accepted. Hence, the wording.
>
> There's a difference between certain people saying something, and 'most
> people think'.  There were only about 15 people that participated in this
> thread, and of those, I couldn't find any that said that performance is a
> weak argument.  Most didn't comment about performance at all.
>
> I could find some that said the opposite, including Ben Ramsey:
> "A UUID generator in the core will only help to improve ramsey/uuid,
> providing more choice and better performance."
> The 'only' there might be confusing, but it's intended in a positive way.
>
> I fail to see how it's possible to derive from that thread a statement
> that 'performance is a weak argument', and I do think it's bad to have a
> ratified php.net RFC that would make that statement as if it's an obvious
> truth.
>
> > > Regardless of being final, they'll become a basic building block in
> apps, and
> > taking them away or modifying them means substantial breakage.  The very
> > introduction of the class, its name (and to a lesser degree its
> functionality) - are
> > tickets with remarkably expensive cancelation options.
> > >
> > > Zeev
> > >
> >
> > This is true for any addition to the language, and imho not an argument
> against
> > the inclusion of new features. I did my very best to create a good API
> that is
> > useful in daily life. I understand that you prefer procedural
> programming, and I
> > understand that you do not see the value of type safety. I prefer OO,
> like the
> > majority of today's PHP community, and I prefer type safety, and the
> > implementation is the result of these preferences. Feel free to create
> > procedural aliases, like we have it for almost all other classes in
> core. I think
> > one way to do things is better, but I also know that this is not the PHP
> way.
> > Confusing APIs and multiple ways to do the same thing is the status quo.
> I
> > believe we should break out of that, and cleanup, but many others don't
> ... alas.
> > Another reason to leave PHP behind.
>
> First, I do not prefer procedural programming.  Personally I use OO a lot
> more than I use procedural.  This is, however, completely besides the point
> - when designing and maintaining PHP, I put my personal preferences aside
> and try to think about what's right and consistent for the language.  I
> think everyone who contributes should do the same.
> Secondly, and very much related, suggesting "I'll do half the job, you can
> do the other half if you want" is very much the wrong approach IMHO.  When
> introducing a new feature, we should strive to make it consistent across
> the board, catering to the wide range of users in our community, and not
> half baked according to the individual preferences of the subsets of the
> language one likes.
> Thirdly, there's nothing inherently confusing about procedural APIs, or
> inherently clear about OO APIs.  Yes, some of our legacy APIs are a mess,
> and it's a tough problem to tackle - but this has nothing to do with not
> wanting to introduce a procedural API for creating a UUID.  The
> procedural/OO duality is not at all what people complain about when griping
> about PHP's API mess.
> Last, yes, the rationale is indeed true for most additions to the
> language.  The 2/3 barrier, as is explained in the Voting RFC (
> wiki.php.net/rfc/voting), has a rationale - the rationale being that
> unlike changes in apps or frameworks, changes to the language have an
> immense cost of reversal or incompatible alteration.  Adding a top level
> object that's four letters long falls squarely within that definition -
> unlike, say, deciding when to release version X, or whether to call version
> Y "8.0" or "10.0".  Looking at it from the other end - fast forward into
> 2021 a world where the current UUID proposal is accepted as-is, would we
> feel comfortable deprecating it with 50%+1 majority?  If the answer's no,
> introducing it shouldn't be at 50%+1 either.
>
> Zeev
>
>
>

--089e0823899478361a055859750f--