Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[DI] Update Container::getEnv phpdoc#23889

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed
ro0NL wants to merge1 commit intosymfony:3.3fromro0NL:di/env
Closed

[DI] Update Container::getEnv phpdoc#23889

ro0NL wants to merge1 commit intosymfony:3.3fromro0NL:di/env

Conversation

@ro0NL
Copy link
Contributor

@ro0NLro0NL commentedAug 14, 2017
edited
Loading

QA
Branch?3.3
Bug fix?yes
New feature?no
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets#...
LicenseMIT
Doc PRsymfony/symfony-docs#...

@ro0NLro0NL changed the title[DI] Fix default default env to string conversion[DI] Fix default env to string conversionAug 14, 2017
@nicolas-grekas
Copy link
Member

nicolas-grekas commentedAug 14, 2017
edited
Loading

Why? There is at least one case that is broken by the forced cast to string: default value identification. If the default of an env is eg null, userland code is able to spot that, when it matters.
About the instanceof check in getEnv, how can that happen? Is it only a ContainerBuilder thing? If yes, should we override the method in ContainerBuilder instead?

@ro0NL
Copy link
ContributorAuthor

ro0NL commentedAug 14, 2017
edited
Loading

Spotted while playing around with it really :) i qualified it a bug.. at least unexpected.

default value identification

Honestly i thought we only allowed scalars/null because we can cast them to string, and so is a real possible env value. Im not sure about getting different types depending on real var existence yes/no. But preserving default null as a feature makes sense 👍 (as you can already set an explicit empty string).

Is it only a ContainerBuilder thing? If yes, should we override the method in ContainerBuilder instead?

Yes (twice :))

@ro0NL
Copy link
ContributorAuthor

@nicolas-grekas not sure about moving to ContainerBuilder.. Container is constructed with a EnvPlaceholderParameterBag so this can happen in Container as well. Ive added a isCompiled check for that.

continue;
}
if (is_numeric($default =$this->parameters[$name])) {
if (is_scalar($default =$this->parameters[$name])) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

👎 for changing this class, we should not cast to string. There is no reason to do so.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Can you explain the rationale... it already casts numbers to string. I assumed this should be any scalar; also null doesnt happen here due isset().

At this point cant we simply removeEnvPlaceholderParameterBag::resolve()?

return$this->envCache[$name] =$env;
}
if (!$this->hasParameter("env($name)")) {
if (!$this->isCompiled() &&$this->parameterBaginstanceof EnvPlaceholderParameterBag) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't think that's correct: when the container is not compiled, env values should not be used - only placeholders should be, so that we can latter on know where an env has been injected.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Im not sure; isnt getEnv() always about getting real env values? If it's a EnvPlaceholderParameterBag we always need to get real value from parent::get.

Doing this from ContainerBuilder::getEnv will be a pain.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Updated so it keeps callinggetParameter(); thus registers placeholders.

@nicolas-grekas
Copy link
Member

read again, I think this PR is wrong, there is nothing to fix here, that's on purpose.

@nicolas-grekasnicolas-grekas added this to the3.3 milestoneAug 15, 2017
@ro0NL
Copy link
ContributorAuthor

Hm to be clear you propose to pass types as is? If you configure it's as a bool you get a bool, if you define a string you get a string? Until a real var exists...

To me that's a trap and i will go with explicit string configs then =/ but imo SF should just cast (except for null) and force the type consistency.

@nicolas-grekas
Copy link
Member

the only thing that might be changed is the "scalar" return type on getEnv, which should be "mixed" yes

@ro0NLro0NL changed the title[DI] Fix default env to string conversion[DI] Fix default env resolutionAug 15, 2017
@ro0NL
Copy link
ContributorAuthor

Updated to mixed return, fair enough 👍

@ro0NLro0NL changed the title[DI] Fix default env resolution[DI] Update Container::getEnv phpdocAug 15, 2017
@ro0NL
Copy link
ContributorAuthor

@nicolas-grekas i reverted the most and kept@mixed return. This basically enables#20276 whereas currently it can happen if you mess with the paramater bag :) Only EnvBag enforces scalars, thats fine.

@ro0NL
Copy link
ContributorAuthor

Last; i think resolveEnvPlaceholders should not escape if compiled.. but im not sure it cares about state here.

@nicolas-grekas
Copy link
Member

Replaced by#23899

@ro0NLro0NL deleted the di/env branchNovember 18, 2017 10:43
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas left review comments

Assignees

No one assigned

Projects

None yet

Milestone

3.3

Development

Successfully merging this pull request may close these issues.

3 participants

@ro0NL@nicolas-grekas@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp