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

[DependencyInjection] [RFC] Plain array configs#11953

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

Conversation

@unkind
Copy link
Contributor

QA
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
LicenseMIT
Doc PRn/a

In this PR I want to discuss the following config format:

<?phpuseSymfony\Component\DependencyInjection\ContainerInterface;return ['parameters' => ['foo' =>42,'bar' =>'bar'    ],'services' => [// à la Pimple, by default'foo' => ['class' => FooBarBaz::class,'factory_method' =>function (ContainerInterface$container) {returnnewFooBarBaz($container->getParameter('foo'));            }        ],// with arguments'bar' => ['class' => FooBarBaz::class,'factory_method' =>function ($bar) {returnnewFooBarBaz($bar);            },'arguments' => ['%bar%']        ]    ]];

There are some reasons to use plain arrays instead of YAML/XML in some cases:

  1. Short array syntax was introduced years ago and it minimises difference between YAML and plain array in readability.
  2. Class name resolution allows IDE to find class usages, apply renaming, go to class by click, etc.
  3. Expression language is nice, but it looks awkward in YAML/XML configs (well, at least for me). My point is to use closures for inline logic instead.

The main disadvantage of plain array against YAML/XML is lack of sandboxing. It can lead abusing of code in configs. But on other hand pure PHP config format has the same problem.

Unfortunately, I see some problems in order to create real PR:

  1. My PR depends onSuper Closure library for dumping closure's code, but I'm not sure if you accept it. By the way, onlycontext free closures can be dumped, it's some sort of restriction.
  2. PhpFileLoader already holds *.php extension, so order of loaders matters.

What do you think?

@fabpot
Copy link
Member

AFAIU, this PR is about two unrelated things: support for closure and a new PHP format. I think it would help to separate the two.

@stof
Copy link
Member

I agree that it should be split into independant PRs. It will be easier to discuss and review (and will give us the possibility to vote for the features separately)

Copy link
Contributor

Choose a reason for hiding this comment

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

requires a ClosureDumperInterface implementation set in order to dump closures

@GromNaN
Copy link
Member

👍 for both features.

@unkindunkind changed the title[DIC] [RFC] Plain array configs[DependencyInjection] [RFC] Plain array configsSep 24, 2014
@stof
Copy link
Member

given that you have split the closure support in a separate PR, the correspondign code should be removed from this branch

@unkind
Copy link
ContributorAuthor

It would be better to create new issue with discussion about array config format, this PR now looks messy as it is tighly coupled with closures conception.

@unkindunkind closed thisSep 24, 2014
@unkindunkind deleted the feature-plain-array-dic-configs branchSeptember 24, 2014 08:26
@unkindunkind mentioned this pull requestDec 27, 2016
@ro0NLro0NL mentioned this pull requestDec 28, 2016
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@unkind@fabpot@stof@GromNaN@cordoval

[8]ページ先頭

©2009-2025 Movatter.jp