This would be inconsistent with therootDir 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 lotprotected 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() makesrootDir obsolete, we should remove it on the long run, no need for changing this now.

Is it really required consideringit's already computed once usingKernel::getProjectDir() and then stored in theKernel::$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 ofgetProjectDir 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 asetRootDir 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 withprojectDir, as we cannot override it after__construct (even thoughgetKernelParameters has not been called yet).

If this is to be merged, the method must not be called on the constructor, otherwise calling the method ingetKernelParameters 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 customgetProjectRootdir() 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 assignationon this line in this PR too, as discussed (as it's already done in theKernel::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.