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

[Yaml] Added support for parsing PHP constants#18626

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

Merged
fabpot merged 2 commits intosymfony:masterfromHeahDude:feature/yaml-php-const
Jun 23, 2016

Conversation

@HeahDude
Copy link
Contributor

@HeahDudeHeahDude commentedApr 24, 2016
edited
Loading

QA
Branch?master
Bug fix?no
New feature?yes
BC breaks?no
Deprecations?no
Tests pass?yes
Fixed tickets~
LicenseMIT
Doc PRTODO

GromNaN, SofHad, Oliboy50, chalasr, and iakunin reacted with thumbs up emoji
@HeahDude
Copy link
ContributorAuthor

I was readinghttp://symfony.com/doc/current/components/dependency_injection/parameters.html#constants-as-parameters and felt sad about the note for yaml support.

Is this PR acceptable? Does this need a flag? Or to be reversible (which does not seem doable)?

There is no sense to handle such case with the dumper imho (unless it is passed as a string?? but what would be the use case?).

@hhamon
Copy link
Contributor

I'm -1 for such horrible hacks. YAML is not a suitable format to handle metada like describing a thing is a constant.

@xabbuh
Copy link
Member

Usually I would agree with@hhamon and I had the same feeling when reading the headline of this PR. But on the other hand@fabpot always wanted to have the Yaml component to support the things we need for Symfony (i.e. being able to configure the framework) instead of supporting the full YAML specs. Now, this is something that is supported by other configuration formats (i.e. PHP and XML), but which isn't supported for the YAML config format. Thus, I am 👍 for closing the gap.


return;
case0 ===strpos($scalar,'!php/const:'):
return @constant(substr($scalar,11));
Copy link
Member

Choose a reason for hiding this comment

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

I think we should to throw aParseException here if the constant does not exist (or at least do that when thePARSE_EXCEPTION_ON_INVALID_TYPE flag is set).

Copy link
ContributorAuthor

@HeahDudeHeahDudeApr 24, 2016
edited
Loading

Choose a reason for hiding this comment

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

I agree, I first did it because this flag looks indeed appropriate. I don't know why I've reverted it.

So I'll push it quickly :)

Copy link
Member

Choose a reason for hiding this comment

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

Well, now that I think of this again, I do not think we should evaluate the flag for this. Such an error imo should never be silenced.

Copy link
ContributorAuthor

@HeahDudeHeahDudeApr 24, 2016
edited
Loading

Choose a reason for hiding this comment

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

It's not an error, it's a warning, preventing to getnull, remove the@ and the last test fails because it gets0.0 instead ofnull. That's why I silenced it (and removed the flag in the process without giving it a second thought).

Copy link
Member

Choose a reason for hiding this comment

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

What I mean is that this usually indicates a mistake made by the developer when writing the YAML file.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Ok I now see you answered before me, I maintain my proposal though, but I'm not against yours.

Still I would rather not add a new flag for this, the goal here is to ease configuration ; currently you need to import anxml or aphp file whileyaml is very common (I think and always used it only).

So needing to add a flag does not seem to "keep it easy" while usingPARSE_EXCEPTION_ON_INVALID_TYPE looks more like "keep doing as usual, just pass a constant if you want".

Copy link
Member

Choose a reason for hiding this comment

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

@HeahDude Well, for the configuration of services the users would not have to do that. It's the responsibility of us to set up the parser properly in theYamlFileLoader. So we are more talking about someone who uses the parser in their own code.

Copy link
ContributorAuthor

@HeahDudeHeahDudeApr 24, 2016
edited
Loading

Choose a reason for hiding this comment

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

Understood! So I need to:

  1. add a flag likePARSE_PHP_CONSTANTS inYaml class
  2. either throw aParseException or returnnull when the constant does not exist
    maybe usingPARSE_EXCEPTION_ON_INVALID_TYPE
  3. add the flagPARSE_PHP_CONSTANTS toYamlFileLoader config.

Is that correct? What about point 2?

Copy link
Member

Choose a reason for hiding this comment

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

I agree. And I think as you would then have to deliberately turn on the feature, throwing an exception when a constant does not exist is the right way.

Copy link
ContributorAuthor

@HeahDudeHeahDudeApr 25, 2016
edited
Loading

Choose a reason for hiding this comment

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

I'm almost there :)

Since the constant are not autoloaded (IIUC), one may expect to getnull if a constant is not defined in an environment, so I guess we can take advantage of the triggeredE_WARNING (refhttp://php.net/manual/en/function.constant.php) as it will be shown as a silenced error in the profiler thanks to#16760.

Hence, I suggest we only trigger an exception whenPARSE_EXCEPTION_ON_INVALID_TYPE flag is passed.

EDIT then it could be up to the user to testnull !== $constant when no exception is thrown(?)

I already did such implementation but I've got an issue when the constant is not "inlined":

foo:    -'!php/const:PHP_INT_MAX'# does not workbar:['!php/const:PHP_INT_MAX']# worksbaz:{ foo: '!php/const:PHP_INT_MAX' }# works

I think it comes from theParser as I only changed theInline class for now, any lead ?

Thanks.

@linaori
Copy link
Contributor

I would be really happy to see this implemented. I prefer yaml over xml by a lot for non-public packages, but not having constants is a big limitation to yaml :(

@HeahDudeHeahDudeforce-pushed thefeature/yaml-php-const branch from4f0835c toa58d960CompareApril 25, 2016 09:36
3.2.0
-----

* added support for PHP constants in yaml configuration files
Copy link
Member

Choose a reason for hiding this comment

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

YAML

HeahDude reacted with thumbs up emoji
@HeahDudeHeahDudeforce-pushed thefeature/yaml-php-const branch 2 times, most recently from09134dc to06fcb9fCompareApril 25, 2016 13:03
@HeahDude
Copy link
ContributorAuthor

Ok, comments addressed, tests are green :)

I guess the failure on low depth will have to wait for master to point on 3.2.

@dunglas
Copy link
Member

Supporting PHP constants would be nice but the proposed syntax!php/const:PHP_INT_MAX is not intuitive and looks ugly. Can we have another nicer syntax?

@HeahDude
Copy link
ContributorAuthor

@dunglas suggestions are welcome! It actually matches the object syntax!php/object, so I thought it would be both consistent and easy to learn. Have you something else in mind?

@HeahDude
Copy link
ContributorAuthor

Could be like float or binary!! constant PHP_INT_MAX.


return;
case0 ===strpos($scalar,'!php/const:'):
if (self::$constantSupport) {
Copy link
Member

Choose a reason for hiding this comment

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

receiving null when a constant does not exist makes debugging very hard when you make a typo

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

@stof there is a hidden conversation on a diff above between me and@xabbuh where we argue about this. It returnsnull but there is a warning logged as silenced error thanks to#16760.
Isn't that enough? Maybe we could also silence it in master for theXmlLoader?

Copy link
Member

Choose a reason for hiding this comment

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

well, IMO, we should not silence things here

Copy link
ContributorAuthor

@HeahDudeHeahDudeApr 29, 2016
edited
Loading

Choose a reason for hiding this comment

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

It would be consistent with the currentXmlLoader indeed. Butnull will be returned anyway with anE_WARNING.

Choose a reason for hiding this comment

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

We shouldn't we trigger an exception when the const is not defined? Would look better to me ATM

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Is there a way to distinguishnull when assigned to a constant from when it's not defined?

Choose a reason for hiding this comment

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

yes, usingdefined()

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

OK great! Then we should do it indeed. What do others think?@xabbuh@stof

@stof
Copy link
Member

Could be like float or binary !! constant PHP_INT_MAX.

no it cannot.!!float is part of the Yaml standard. custom tags must star with a single!, not 2

@HeahDude
Copy link
ContributorAuthor

Ok, so why not!constant PHP_INT_MAX? Although I'm not against the current syntax.

dunglas reacted with thumbs up emoji

@xabbuh
Copy link
Member

I would not change the tag name. Thephp: part acts like a Namespace here which reduces the risk to conflict with custom tags from other libraries.

HeahDude and piotaixr reacted with thumbs up emoji

@dunglas
Copy link
Member

@xabbuh it makes perfectly sense but!constant PHP_INT_MAX is really nicer.

@fabpot
Copy link
Member

I'm against adding something that does not follow the YAML specification.

Angel-bgo and robfrawley reacted with thumbs up emoji

@dunglas
Copy link
Member

dunglas commentedApr 29, 2016
edited
Loading

If I understand correctly the spec, both proposals are valid:http://www.yaml.org/spec/1.2/spec.html#id2782728

useSymfony\Component\Yaml\Exception\ParseException;
useSymfony\Component\Yaml\ParserasYamlParser;
useSymfony\Component\ExpressionLanguage\Expression;
useSymfony\Component\Yaml\Yaml;

Choose a reason for hiding this comment

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

can you please move it one line up in the yaml group?

Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

Are you sure about this? The "good way" would be to move up theExpression line but as a CS fix it shouldn't be done in master, right?

Choose a reason for hiding this comment

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

let's group yaml lines now that we can (but we don't move existing lines to reduce merge conflicts)

@HeahDude
Copy link
ContributorAuthor

Comments addressed. Waiting for tests to be green, needs review, thanks!

@fabpot
Copy link
Member

👍

try {
$configuration =$this->yamlParser->parse(file_get_contents($file));
$configuration =$this->yamlParser->parse(file_get_contents($file), Yaml::PARSE_CONSTANT);
}catch (ParseException$e) {
Copy link
ContributorAuthor

Choose a reason for hiding this comment

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

TheSymfony\Component\Yaml\Exception\RuntimeException might not be caught here,@xabbuh any ideas on how we should handle it?

Choose a reason for hiding this comment

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

@nicolas-grekas
Copy link
Member

Status: needs work

@HeahDude
Copy link
ContributorAuthor

HeahDude commentedJun 17, 2016
edited
Loading

Updated.

@HeahDude
Copy link
ContributorAuthor

Status: Needs Review

@fabpot
Copy link
Member

👍 (failures not related)


thrownewParseException(sprintf('The constant "%s" is not defined.',$const));
}
if (self::$exceptionOnInvalidType) {
Copy link
Member

Choose a reason for hiding this comment

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

[...] passthe [...]

Copy link
Member

Choose a reason for hiding this comment

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

[...] be parsed asa constant.

@fabpot
Copy link
Member

@HeahDude Can you take@xabbuh comments into account?

@HeahDudeHeahDudeforce-pushed thefeature/yaml-php-const branch 2 times, most recently from4f861c0 to17ec26eCompareJune 23, 2016 13:44
@fabpot
Copy link
Member

Thank you@HeahDude.

@fabpotfabpot merged commit17ec26e intosymfony:masterJun 23, 2016
fabpot added a commit that referenced this pull requestJun 23, 2016
This PR was merged into the 3.2-dev branch.Discussion----------[Yaml] Added support for parsing PHP constants| Q             | A| ------------- | ---| Branch?       | master| Bug fix?      | no| New feature?  | yes| BC breaks?    | no| Deprecations? | no| Tests pass?   | yes| Fixed tickets | ~| License       | MIT| Doc PR        | TODOCommits-------17ec26e [DI] added support for PHP constants in yaml configuration files02d1dea [Yaml] added support for parsing PHP constants
@HeahDudeHeahDude deleted the feature/yaml-php-const branchJune 23, 2016 14:07
@fabpotfabpot mentioned this pull requestOct 27, 2016
@teohhanhui
Copy link
Contributor

teohhanhui commentedJun 2, 2017
edited
Loading

It's unfortunate that we did not consider it important to adhere to the YAML spec:http://www.yaml.org/spec/1.2/spec.html#tag/local/

EDIT: See#22913 😄

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.

11 participants

@HeahDude@hhamon@xabbuh@linaori@dunglas@stof@fabpot@nicolas-grekas@teohhanhui@javiereguiluz@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp