This would be inconsistent with the rootDir imho?

yes - but we dont care :)

if you want consistency use the method as extension hook for both.

Yes it's inconsistent, but allows for better maintainability and user experience at the end. There is a lot protected members in the core codebase, but since a long time, we do not introduce new ones without a strong reason, and we even made some private afterwards (generally through "opportunity").
Also, getProjectDir() makes rootDir obsolete, we should remove it on the long run, no need for changing this now.

Is it really required considering it's already computed once using Kernel::getProjectDir() and then stored in the Kernel::$projectDir property ?

@ogizanagi is right, but I think it's better to always call the method. If the constructor behavior changes a day, and given the method itself return the property if initialized, I think it's sane to use it rather than the prop.

@ogizanagi you could add a method in your kernel that modifies the return value of getProjectDir between the moment the object is created and the moment the container is compiled.

you could add a method in your kernel that modifies the return value of getProjectDir between the moment the object is created and the moment the container is compiled.

That is exactly the point. Originally, we had a setRootDir method to tell the Kernel where it's root dir is located. Because our kernel is distributed with a bundle but the root dir is still /app. Now that does no longer work with projectDir, as we cannot override it after __construct (even though getKernelParameters has not been called yet).

If this is to be merged, the method must not be called on the constructor, otherwise calling the method in getKernelParameters does not make much sense to me.

Agree; not sure what's the lazy initialization is about. But it doesnt harm really :)

otherwise calling the method in getKernelParameters does not make much sense to me.

I don't think so. The getter is the extension point. The private property is set at construction so that it is always available internally; and the method is called when needed. As pointed by @jvasseur, the kernel state can change after construction, always calling the method is just safe-guard, that's fine to me.

you could add a method in your kernel that modifies the return value of getProjectDir between the moment the object is created and the moment the container is compiled.

the kernel state can change after construction

Changing this value after initialization looks weird to me honestly, so I don't really get the point, but ¯\_(ツ)_/¯.

Not only the value itself, but some other properties on which the custom getProjectRootdir() could rely on... it's all about weird edge cases, but preventing them in the parent class doesn't harm, and since we can do it easily...

@chalasr: What about removing the the assignation on this line in this PR too, as discussed (as it's already done in the Kernel::getProjectDir() implementation) ?

The private property is set at construction so that it is always available internally; and the method is called when needed.

The property must not be used internally (except for the getter method) if the getter is to be the extension point! So there's no point in initializing it.

Tend to agree with that :) it also makes the test valid.

constructor assignment removed, changed the test to better show what this prevents.

ping @symfony/deciders

👍

Thank you @chalasr.