@nikophil I fixed test fixtures! Please review again.

Maybe we should modify PersistentObjectFactory in a way that it could handle the case where $autorefreshEnabled has never been initialized?

I think since PersistentObjectFactory::$autorefreshEnabled is initialized to false, there should be no problem even if we do not modify it.

However, if we would like to take maximum consideration into account users who are unintentionally missing out on the benefits of autorefresh due to this bug, we may be able to take additional measures, such as the following:

• Change the initial value of PersistentObjectFactory::$autorefreshEnabled to null.
• Just before using PersistentObjectFactory::$autorefreshEnabled, if a condition such as Configuration::autoRefreshWithLazyObjectsIsEnabled() && $factoryUsed->autorefreshEnabled is met, emit an E_WARNING level error (or some similar warning) and just treat $factoryUsed->autorefreshEnabled as false.

I fixed test fixtures! Please review again.

cool thanks

I think since PersistentObjectFactory::$autorefreshEnabled is initialized to false, there should be no problem even if we do not modify it.

not sure... think of this situation:

# config/packages/zenstruck_foundry.yaml
zenstruck_foundry:
    enable_auto_refresh_with_lazy_objects: true

class SomeFactory extends PersistentObjectFactory
{
    public function __construct(
        // ... some dependencies ...
    ){
        // no call to parent
    }
}

the user explicitly asks for auto refresh to be enabled. But PersistentObjectFactory's constructor won't be called, then it will be disabled.

I think we should do something like that:

// PersistentObjectFactory

private bool|null $autorefreshEnabled;

private function isAutorefreshEnabled(): bool
{
    return $this->autorefreshEnabled ??= Configuration::autoRefreshWithLazyObjectsIsEnabled();
}

and use isAutorefreshEnabled() anytime we want to access the variable

WDYT?

@nikophil

I think we should do something like that:
WDYT?

In conclusion, I completely agree.

I think there are two possible approaches for existing users whose automatic updates are disabled due to this bug.

1. When you upgrade to the next version, the automatic update settings will be correctly reflected, and automatic updates that were previously (unintentionally) disabled will be enabled.
2. To minimize the impact to users, even when upgrading to the next version, simply issue a warning to encourage the parent constructor to be called, and do not enable automatic updates.

Option 2 is the most cautious approach, but it could be considered a bit excessive.

Personally, I think option 1 is fine. And in that case, I think the example you provided is a very safe and good approach.

In any case, I don't think there's any need to address this issue in this PR.

Why not merge this PR for now and address any additional issues in a separate PR?

Actually, I do think if we implement the approach I'm suggesting, we do not need to impact the template : we should remove the constructor from PersistentObjectFactory and initialize the prop when needed

using the constructor was a mistake in the first place. Sorry for the work which needs to be undone

Ah, I understand. You're absolutely right. I'll update the PR later!

thank you!

thanks @ttskch

released https://github.com/zenstruck/foundry/releases/tag/v2.7.4