Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support some new features from the updated spec #25

Merged
merged 1 commit into from Sep 13, 2023

Conversation

mszabo-wikia
Copy link
Contributor

Handle accessing section data at the top of the context via {{.}} and add special-case handling for null sections. With these changes, all test cases from the spec pass, except for optional new features that are not yet implemented.

The specs submodule was updated in this PR only to verify this in CI as well. It can be restored to point back to the fork prior to merge.

Handle accessing section data at the top of the context via {{.}} and
add special-case handling for `null` sections. With these changes, all
test cases from the spec pass, except for optional new features that
are not yet implemented.

The specs submodule was updated in this PR only to verify this in CI as
well. It can be restored to point back to the fork prior to merge.
@mszabo-wikia
Copy link
Contributor Author

@mszabo-wikia
Copy link
Contributor Author

mszabo-wikia commented Jun 2, 2023

Alternatively the UTF-8 test could be converted into a unit/regression test, removing the need to maintain a forked spec - what do you think?

@jbboehr jbboehr mentioned this pull request Sep 13, 2023
@@ -86,7 +86,7 @@ int Data::isEmpty()
ret = 1;
break;
case Data::TypeString:
if( val == NULL || val->length() <= 0 ) {
if( val == NULL || val->length() <= 0 || *val == "null" ) {
Copy link
Owner

@jbboehr jbboehr Sep 13, 2023

Choose a reason for hiding this comment

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

I think this may be better handled in the specification parsing code, as I don't think it's optimal to generally treat a string containing "null" as empty. Unfortunately, libyaml, being a c, not a c++, library, is fairly low level and doesn't handle any type conversions automatically. See e.g. #18.

This (probably) isn't an issue with the PHP extension as it has it's own conversion code using native PHP types.

I've opened another PR in #26 with this change applied but let me know if you disagree or if it breaks your use-case or w/e.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense, I think I just misinterpreted the spec there and didn't realize that was only for literal nulls.

@jbboehr jbboehr closed this in 3b30075 Sep 13, 2023
@jbboehr jbboehr merged commit eb149df into jbboehr:master Sep 13, 2023
7 of 9 checks passed
@jbboehr
Copy link
Owner

jbboehr commented Sep 13, 2023

Looks good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants