Nette DI: suspicious dumping of objects when generating the container

[Gappa]

Version: 3.2.0

Bug Description

User Notice
Nette DI: suspicious dumping of objects TestExtensionConfigDTO when generating the container

Steps To Reproduce

final class TestExtensionConfigDTO
{
	// empty class is enough 
}


final class TestExtension extends \Nette\DI\CompilerExtension
{
	public function getConfigSchema(): Schema
	{
		return Expect::from(new TestExtensionConfigDTO);
	}
}

extensions:
	- TestExtension

Expected Behavior

No error message is shown or a message that is better at explaining what is suspicious about the object/class and how to fix it.

Possible Solution

N/A

---

I'm not really sure what to do about this or what actually is the problem - I'm using objects like this:

• https://doc.nette.org/en/schema#toc-mapping-to-objects-from

Edit - relevant commit:

• c257fa9

[dg]

It looks like the TestExtensionConfigDTO object can't be simply created, so it is created in the container using Dumper::createObject(), i.e. using serialization+unserialization, which is a pretty dirty way.

https://github.com/nette/php-generator/blob/08ab9bff22ae34fe4e1d2fe8ba16b3770ea2459f/src/PhpGenerator/Dumper.php#L290-L297

But I understand why you use it that way, let's try to find a solution.

The solution I can think of is that TestExtensionConfigDTO will have a constructor (and all properties will be promoted parameters), so such an object can be easily created. But that's not enough, some information will still have to be added for the DI compiler to use that constructor…

[mabar]

I am confused what does it have to do with DI compiler. Isn't config schema used just to access config values of the extension? They are not passed to generated DIC

For objects that are passed to generated DIC, I am using explicit serialization, which is fine as long as changing the object forces DIC to regenerate (can be done by adding object to compiler dependencies) https://github.com/orisai/localization/blob/ae99720c58b10408b099e68c9692f75a45c4b627/src/Bridge/NetteDI/LocalizationExtension.php#L131-L136

[dg]

@mabar I suppose @Gappa will then pass the $this->config to some service. Right?

[Gappa]

@mabar I suppose @Gappa will then pass the $this->config to some service. Right?

Yes, that is correct.

[janfejtek]

I think having some better decision making when triggering error would be fine? Plus some changes in Dumper::createObject logic to avoid unserialization. Maybe some similar logic to form values? https://github.com/nette/forms/blob/d42a22b451fcdf267e7c485309370506a8731d56/src/Forms/Container.php#L137

If I have simple class like this

class Data {
   public string $url;
   public string $query;
}

I would say it is really close to \stdClass, but it is not accepted
c257fa9#diff-b01fda112fb0df465a70dd098f3843dd90fc3a0ce514c37ef38d620e7f7cc718R184

[dg]

I don't know how to dump this object:

class Data {
   public string $url;
   public string $query;
}

but I can dump this one:

class Data {
  function __construct(
   public string $url,
   public string $query,
  ) {}
}

[Gappa]

Tried it with 6b9910cece1e074ad1d1babc6a62c48dfa9ea870 and it works now - thanks. 👍

However, would it be better if I changed those DTOs to classes with private properties and a constructor?

[dg]

@Gappa I'm not sure yet, I'll let you know