Static factory

[roxblnfk]

Hello.
Is there any thought about adding a way to recreating identifiers through static methods?

Like it used to be with UUIDs: Uuid::fromString().
From my perspective, it seems strange that I have to populate a factory's state to get some object representation of an identifier from the database.

Or is it implied that now we should create identifiers directly via the constructor?

[puzzledpolymath]

My understanding is that Snowflakes need to be handled a little differently, as in the epoch offset is required when converting to a DateTime object. Which in turn is used when comparing Snowflake to other identifiers.

We can't do much about the lack of static factories, Ben has taken a more object oriented approach doing away with static methods. However my recent changes to cycle/entity-behavior-identifier#5 resolves the broken code and issues discussed here.

There is also another PR cycle/orm#529 which is required for all this to work correctly, allowing supplied attributes to be passed to typecast rules and later used when casting the database values.

[ramsey]

I have to populate a factory's state

Can you elaborate what you mean by populating its state?

is it implied that now we should create identifiers directly via the constructor?

Not at all. You can provide the instantiated factory to an object’s constructor (use a factory interface as the parameter type), and wherever you need to create UUIDs within the class, use the factory to create them, instead.

If you use a dependency injection library, you might be able to set it up to autowire creation of the UUID factory when creating your objects.

[puzzledpolymath]

Can you elaborate what you mean by populating its state?

I believe what Aleksei is questioning is; In ramsey/uuid you could simply call Uuid::fromString($value) to create a UUID instance.

Whereas now, a factory class must be instantiated in order to create an identifier. E.g.

$factory = new UuidV4Factory();
$uuid = $factory->createFromString($value);

Not a big deal IMO, however Snowflake identifiers have proven trickier, or required more underlying changes to cycle/orm and cycle/entity-behavior-identifier than anticipated. The reason being, Snowflake factories within ramsey/identifier require constructor dependencies (knowledge of how they were conceived), which I think Aleksei is referring to as "state". For example.

// Do stuff, retrieving $identifier from database etc.
$identifier = '...';

// Without storing state, a Snowflake cannot be derived without knowing $nodeId, $epochOffset
// Correction - It can be created, however $snowflake->getDateTime() would not be accurate
$factory = new GenericSnowflakeFactory($nodeId, $epochOffset);
$snowflake = $factory->createFromInteger($identifier);

[roxblnfk]

Can you elaborate what you mean by populating its state?

I mean that if I need to create a DiscordSnowflake object from a DB value, I have to specify required $workerId and $processId. However, $workerId and $processId are not necessary for creating an identifier from known value.
This is the "state" that varies by process and worker and is used only for creating new identifiers.

If you use a dependency injection library, you might be able to set it up to autowire creation of the UUID factory when creating your objects.

Just to note, not all tools will have access to Container or DI. DI can be considered a side effect, which might disrupt determinism in most cases.

If we discard factories and start creating identifiers directly, also consider that a static method might be preferable to a constructor: a static method easily becomes a convenient callable like [class, method] because it serializes well into JSON.

---

It can be created, however $snowflake->getDateTime() would not be accurate

I didn't notice that GenericSnowflake has the required epochOffset parameter. Thank you for pointing that out. It seems that only the epochOffset for GenericSnowflake needs to be persisted in the ORM schema.

Okay, I agree with @puzzledpolymath, so we can create our own static factories with some boilerplate.