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] deprecate most characters in service ids#18028

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

Conversation

@xabbuh
Copy link
Member

QA
Branchmaster
Bug fix?no
New feature?no
BC breaks?no
Deprecations?yes
Tests pass?yes
Fixed tickets#17801
LicenseMIT
Doc PRTODO

publicfunctionsetAlias($alias,$id)
{
if (preg_match('/[^a-z0-9\._]/i',$alias)) {
trigger_error(sprintf('Using characters other than A-Z, 0-9, ., and _ in service ids ("%s" given) is deprecated since Symfony 3.1 and will throw an exception in 4.0.',$alias),E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be silenced

@xabbuh
Copy link
MemberAuthor

Comments addressed, tests fixed.

Status: Needs Review

publicfunctionset($id,$service)
{
if (preg_match('/[^a-z0-9\._%]/i',$id)) {
@trigger_error(sprintf('Using characters other than A-Z, 0-9, ., and _ in service ids ("%s" given) is deprecated since Symfony 3.1 and will throw an exception in 4.0.',$id),E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

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

Instead of:

... and will throw an exception in 4.0.

We use this other wording in most deprecation notices:

... and will be removed in 4.0.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Yeah, but that sounds really weird in this context (for example, in the Yaml component we used "will throw a ParseException" too).

Copy link
Member

Choose a reason for hiding this comment

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

OK. It makes sense. Thanks.

@javiereguiluz
Copy link
Member

👍

Status: Reviewed

@nicolas-grekas
Copy link
Member

should we allow non western users to use utf8 to name their services? I'm sure some do and I don't see anything wrong. wdyt?

sstok and jvasseur reacted with thumbs up emoji

@xabbuh
Copy link
MemberAuthor

Can we make sure that non of them will cause trouble in the future?

@GuilhemN
Copy link
Contributor

What do you think about allowing/ and\?
I already faced cases where it is useful to have different separator for clarity. (in case you have a lazy wrapper for a service you may want to name it@lazy/vendor.service_id)

Exter-N reacted with thumbs up emoji

@javiereguiluz
Copy link
Member

@xabbuh given the comments made by some reviewers (support non-English UTF8 chars, support slashes and backslashes, etc.) what do you think about switching to a blacklist filter instead of the current whitelist filter? Let's ban some concrete chars (@, dashes, ASCII control chars, etc.) and let's allow everything else.

sstok reacted with thumbs up emoji

@xabbuh
Copy link
MemberAuthor

@javiereguiluz We could do that too. The list should then probably contain whitespace characters, control sequences,!,?,@, quote characters, backticks, dashes. Anything else of importance?

GuilhemN reacted with thumbs up emoji

@javiereguiluz
Copy link
Member

@xabbuh I can't think of anything else. Your list looks comprehensive. Thanks!

@xabbuhxabbuhforce-pushed thedeprecate-special-chars-service-ids branch 2 times, most recently from1e1f353 to097ae80CompareMarch 14, 2016 18:09
@xabbuh
Copy link
MemberAuthor

changed the PR to use a blacklist instead of a whitelist

@stof
Copy link
Member

the whitelist should be built in a way where the generated method names for the dumping of the container generates a valid name (which means adding more stuff to the allowed whitelist).
Building a real blacklist may be much harder, as we have a whitelist for PHP method names

@GuilhemN
Copy link
Contributor

@stof isn't it possible to convert the services' id to another base to have only supported characters (maybe usingbase_convert andord) ?

Edit: at worst, if we really want to keep descriptive name as much as possible, we could solve the actual limitation of the dumper by having a counter which would be incremented each time a new unsupported service id is camelized.

@GuilhemN
Copy link
Contributor

Can you take a look at#18167 please?
This should fix the initial issue with thePhpDumper and allow you to use a black list.

@fabpot
Copy link
Member

#18167 has been merged now

@xabbuhxabbuhforce-pushed thedeprecate-special-chars-service-ids branch from8bbb655 tod06bb91CompareApril 6, 2016 18:44
@xabbuh
Copy link
MemberAuthor

rebased here

ping @symfony/deciders

@GuilhemN
Copy link
Contributor

What about deprecating an empty string as service id at the same time ? (see#18265 (comment))

$definition->setPublic($public);
$definition->addTag('console.command');
$container->setDefinition('my-command',$definition);
$container->setDefinition('app.command',$definition);

Choose a reason for hiding this comment

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

I don't get why we need to reject-? Could we allow it?

@stof
Copy link
Member

stof commentedApr 8, 2016

Do we actually still need this ?

@fabpot
Copy link
Member

Indeed, let's close this then.

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.

8 participants

@xabbuh@javiereguiluz@nicolas-grekas@GuilhemN@stof@fabpot@Taluu@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp