Skip to content

[UID] Added the component + Added support for UUID #35940

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 12, 2020

Conversation

lyrixx
Copy link
Member

@lyrixx lyrixx commented Mar 3, 2020

Q A
Branch? master
Bug fix? no
New feature? yes
Deprecations? no
Tickets
License MIT
Doc PR

<?php

require __DIR__.'/vendor/autoload.php';

use Symfony\Component\Uid\Uuid;

$u = Uuid::v1();
dump($u);
dump($u->isNull());
dump($u->getType());
dump($u->getVariant());
dump($u->getTime());
dump($u->getMac());
dump($u->isEqualsTo($u));
dump($u->compare($u));
dump(Uuid::fromBinary($u->toBinary()));

@stof

This comment has been minimized.

@lyrixx

This comment has been minimized.

@lyrixx

This comment has been minimized.

@lyrixx lyrixx force-pushed the string-uuid branch 2 times, most recently from 546a7b9 to 232c30b Compare March 3, 2020 15:55
Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice thank you, very simple!

Why in the string component ?

Because that's where it fits bests to me: the String component gathers simple "string-like" value objects; UUID is an important one of them.

@wouterj
Copy link
Member

wouterj commented Mar 3, 2020

Given the number of UUID libraries in PHP/Symfony land (ref https://jolicode.com/blog/uuid-generation-in-php ), I would say this topic is oversaturated with libraries already. Is there a major pro for this new class instead of the Pecl extension/Symfony Polyfill or Ramsey UUID?

@nicolas-grekas
Copy link
Member

nicolas-grekas commented Mar 3, 2020

Where do you see saturation here? pecl is low level: there need to be a value object in our OOP code. polyfill is ... a polyfill, and FFI+libuuid is a POC. Which means there is only one single available (and mainstream) implementation: ramsey/uuid.
The class proposed here provides the same benefits (a VO), with a very simple implementation.
Ppl that need to do fancy things with uuid - or that need guaranteed portability to 32b systems, will have to resort to ramsey/uuid. But the rest of the world will be happy to leverage a trivial implem.
At least I would.

@wouterj

This comment has been minimized.

@nicolas-grekas
Copy link
Member

this UUID class doesn't add any value on top of the PECL extension/polyfill

It does provide a lot: e.g a VO integrates with Doctrine types. The pecl extension doesn't.

About the doc for deps, there's nothing specific to this PR... The argument would apply to any new feature with optional deps...

@stof

This comment has been minimized.

@fabpot
Copy link
Member

fabpot commented Mar 5, 2020

Agreed on the new component proposal.

@ro0NL
Copy link
Contributor

ro0NL commented Mar 5, 2020

did we consider adding polyfill support for ramsey/uuid? esp. since it has 1st class pecl support already:

https://github.com/ramsey/uuid/blob/b31703e7c9752260ddc773c95110294fa9abc5ff/src/FeatureSet.php#L84
https://github.com/ramsey/uuid/blob/master/src/Generator/PeclUuidNameGenerator.php

Ppl that need to do fancy things with uuid - or that need guaranteed portability to 32b systems, will have to resort to ramsey/uuid

so, we shouldnt resort to ramsey/uuid for simple/non-fancy uuids? i feel like we're defeating it's UuidInterface + the fact most of the ecosystem is using it already.

It does provide a lot: e.g a VO integrates with Doctrine types.

so does ramsey/uuid.

im rather skeptical about vendor-a/uuid + vendor-b/uuid :)

@lyrixx lyrixx changed the title [String] Added support for UUID [UUID] Added the component Mar 5, 2020
Copy link
Contributor

@localheinz localheinz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Looks good to me code-wise.

However, I agree with @theofidry.

I believe the general question the core team need to discuss is whether Symfony wants to follow the same route Zend Framework did about a decade ago (pulling in a component for every single use case), or whether that is really necessary.

Pulling in a component for every single use case has the following down-sides:

  • more work required by maintainers
  • more maintainers required
  • more documentation required
  • more bug fixes required
  • more signal and noise on the central symfony/symfony repository
  • killing successful 3rd-party libraries

Not sure if symfony/symfony really needs to become that big black 🕳, sucking in everything around it.

Copy link
Member

@dunglas dunglas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I've no strong opinion regarding if we need a new component or if we can just rely on ramsey/uuid, but 👍 regarding the code).

@nicolas-grekas

This comment has been minimized.

@OskarStark

This comment has been minimized.

@Taluu

This comment has been minimized.

@nicolas-grekas

This comment has been minimized.

@lyrixx lyrixx changed the title [UUID] Added the component [Uid] Added the component + Added support for UUID Mar 11, 2020
@lyrixx lyrixx changed the title [Uid] Added the component + Added support for UUID [UID] Added the component + Added support for UUID Mar 11, 2020
@wouterj
Copy link
Member

wouterj commented Mar 11, 2020

Just a random thought: Would the idea of the Uid component be stronger if we add a UidInterface contract, that can be used by any unique identifier introduced?

@lyrixx
Copy link
Member Author

lyrixx commented Mar 11, 2020

@wouterj What would be the interface ?

Copy link
Contributor

@OskarStark OskarStark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 minors

Copy link
Member

@nicolas-grekas nicolas-grekas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still good to me after the recent changes. Good to go on my side.

@fabpot
Copy link
Member

fabpot commented Mar 12, 2020

Thank you @lyrixx.

@fabpot fabpot merged commit d108f7b into symfony:master Mar 12, 2020
@lyrixx lyrixx deleted the string-uuid branch March 13, 2020 16:03
@nicolas-grekas nicolas-grekas modified the milestones: next, 5.1 May 4, 2020
@fabpot fabpot mentioned this pull request May 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.