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][Config] Add ContainerBuilder::classExists() for checking and tracking class, interface or trait existence#21452

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

nicolas-grekas
Copy link
Member

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?/no
Tests pass?yes
Fixed tickets-
LicenseMIT
Doc PR-

Subset of#21419

*
* @final
*/
public function getClassExists($class)

Choose a reason for hiding this comment

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

I'm not sure this is the best name for this method. What aboutregisterClass() ortrackClass() or something like that.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

ok for a better name, but it should convey the fact that the return value has a meaning

Copy link
Member

Choose a reason for hiding this comment

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

Hard but I agree,::trackedClassExists()... ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

In fact, tracking is a side effect, so I'm not sure the name should convey that. When a method logs, we don't call it doThatAndLogIt

Copy link
Contributor

Choose a reason for hiding this comment

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

So why not justdoesClassExist/classExists?

chalasr and javiereguiluz reacted with thumbs up emoji

Choose a reason for hiding this comment

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

I was going to proposeisTracked() ... but if tracking is not important...

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

It's not that it's not important : it's a side effect. A conditional one also. What matters most is that this returns if a class exists or not.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

renamed to classExists

javiereguiluz and robfrawley reacted with thumbs up emoji
@nicolas-grekasnicolas-grekasforce-pushed thedi-class-exists branch 3 times, most recently from2839a7e to6140a26CompareJanuary 29, 2017 18:42
@nicolas-grekasnicolas-grekas changed the title[DI][Config] Add ContainerBuilder::getClassExists() for checking and tracking class, interface or trait existence[DI][Config] Add ContainerBuilder::classExists() for checking and tracking class, interface or trait existenceJan 29, 2017
$this->addResource(new ClassExistenceResource($class));
$this->classReflectors[$class] = false;
} else {
$class = $this->classReflectors[$class] = new \ReflectionClass($class);
Copy link
Contributor

Choose a reason for hiding this comment

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

We don't need to store the reflection class, we can storetrue instead, right ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

we do, preparing#21419

GuilhemN reacted with thumbs up emoji
Copy link
Member

Choose a reason for hiding this comment

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

@nicolas-grekas wouldn't this hurt here as we create the reflector without adding a reflection resource, and the getter for the class reflector would not add it later as it is already there in the array

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

that could be an issue, but the code in#21419 is free from it, see
https://github.com/symfony/symfony/pull/21419/files#diff-a10c9afd8feaccd1ff66ffd54e2835bcR356

The reflection resource is always added, even if the cache is hit. This creates duplicate resources, but they are free, and deduplicated later on so not an issue.

*
* @return bool
*
* @final
Copy link
Contributor

Choose a reason for hiding this comment

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

Why using the annotation?

Copy link
MemberAuthor

@nicolas-grekasnicolas-grekasJan 30, 2017
edited
Loading

Choose a reason for hiding this comment

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

becausefinal is a non by-passable imperative keyword, and I don't like it at all for this reason.
@final is way enough to press the intent. We don't need to be dictatorial if people want to do clever things like lazy proxies.

chalasr and GuilhemN reacted with thumbs up emoji
Copy link
Contributor

Choose a reason for hiding this comment

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

Then imo we should have a solution that wouldn't throw a deprecation when used as a proxy. What about checking for a keyword such asmockable and don't throw a deprecation when common proxy interfaces are implemented?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

in fact, we already have one: proxies are not loaded via standard autoloading, so they don't get through DebugClassLoader :)

Copy link
Contributor

@GuilhemNGuilhemNJan 30, 2017
edited
Loading

Choose a reason for hiding this comment

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

Ok I did not know that, it's logic indeed :)

@@ -65,6 +66,9 @@ private function updateDefinition(ContainerBuilder $container, $id, Definition $
if (is_string($factory)) {
try {
$m = new \ReflectionFunction($factory);
if (false !== $m->getFileName() && file_exists($m->getFileName())) {
$container->addResource(new FileResource($m->getFileName()));
Copy link
Member

Choose a reason for hiding this comment

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

shouldn't we use your new reflection resource instead, to invalidate less often ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

If you mean for the function, we don't have a ReflectionFunction resource, and I don't think we need one.

@chalasr
Copy link
Member

Some suggestions innicolas-grekas#10

@nicolas-grekas
Copy link
MemberAuthor

nicolas-grekas commentedJan 30, 2017
edited
Loading

PR is ready, with allclass_exists() replaced by$container->classExists().

BUT

I'm wondering ifClassExistenceResource is required at alland if we shouldn't deprecate it instead (we should not deprecate it because#21419 uses it for userland classes - but still, we couldnot use it for deps related checks).
ping@fabpot because you added it in#20121
should we really need to track things that change only whencomposer is used?
shouldn't we instead expect people/"a composer script" to clear the dumped container when deps change?

the benefit might be just DX, because checking a bunch of classes for existence takes time (even if this PR makes the situation a bit better by using onlyFileExistenceResource when possible).

WDYT?

@fabpot
Copy link
Member

We talked aboutClassExistenceResource with@nicolas-grekas and I'm going to fix my edge case another way, so this class is not needed anymore for classes managed via Composer.

My use case was with projects that don't havesymfony/console, socache:clear is not run by Composer. That's mainly the case when using only the Symfony components with Flex, and I will find another way.

@nicolas-grekasnicolas-grekas deleted the di-class-exists branchJanuary 30, 2017 20:54
fabpot added a commit that referenced this pull requestJan 31, 2017
…ekas)This PR was merged into the 3.3-dev branch.Discussion----------[DI] Remove usages of ClassExistenceResource| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | no| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | -| License       | MIT| Doc PR        | -As discussed in#21452 (see last comments)Commits-------ec8f1ad [DI] Remove usages of ClassExistenceResource
@stof
Copy link
Member

stof commentedFeb 2, 2017

My use case was with projects that don't have symfony/console, so cache:clear is not run by Composer. That's mainly the case when using only the Symfony components with Flex, and I will find another way.

#21505 is the answer to this, right ?

@nicolas-grekas
Copy link
MemberAuthor

yes!

@nicolas-grekas
Copy link
MemberAuthor

Ans also to#21419 (comment)

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@javiereguiluzjaviereguiluzjaviereguiluz left review comments

@stofstofstof left review comments

@ogizanagiogizanagiogizanagi left review comments

@GuilhemNGuilhemNGuilhemN left review comments

@chalasrchalasrchalasr left review comments

Assignees
No one assigned
Projects
None yet
Milestone
3.3
Development

Successfully merging this pull request may close these issues.

8 participants
@nicolas-grekas@chalasr@fabpot@stof@javiereguiluz@ogizanagi@GuilhemN@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp