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

Fix/arithmetic in functions #390

Closed
wants to merge 6 commits into from

Conversation

raxbg
Copy link
Contributor

@raxbg raxbg commented Sep 19, 2022

Builds on top of #169

@oliverklee oliverklee deleted the branch MyIntervals:main February 7, 2024 11:36
@oliverklee oliverklee closed this Feb 7, 2024
@oliverklee oliverklee reopened this Feb 7, 2024
@oliverklee oliverklee changed the base branch from master to main February 7, 2024 22:34
Copy link
Contributor

@JakeQZ JakeQZ left a comment

Choose a reason for hiding this comment

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

Functional changes are all good. A few minor side issues though.

@oliverklee, would you like to see if there is anything else?

I'm aware of two things that I think are beyond the scope of this PR, and part of broader changes we want to make moving forwards:

  • We want to move the test data from files to be inlined with the relevant test code.
  • We want to have class-specific tests as well as general parsing tests (but as yet there is no ValueTest TestCase).

Comment on lines +36 to +64
/**
* @param ParserState $oParserState
* @param bool $bIgnoreCase
*
* @return string
*
* @throws SourceException
* @throws UnexpectedEOFException
* @throws UnexpectedTokenException
*/
public static function parseName(ParserState $oParserState, $bIgnoreCase = false)
{
return $oParserState->parseIdentifier($bIgnoreCase);
}

/**
* @param ParserState $oParserState
*
* @return array
*
* @throws SourceException
* @throws UnexpectedEOFException
* @throws UnexpectedTokenException
*/
public static function parseArgs(ParserState $oParserState)
{
return Value::parseValue($oParserState, ['=', ' ', ',']);
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I like the refactoring. But can the new methods be made private - I presume they are (currently) only intended to be used internally by the class?

Also, since we now have a minimum PHP version of 7.2, the return types can be included in the function declaration (and removed from the DocBlock, since they would then become redundant there). (I know we didn't have PHP>=7.2 at the time this PR was created.)

Comment on lines +1249 to +1252
$sExpected = 'div {height: max(300,vh + 10);}
div {height: max(300,vh - 10);}
div {height: max(300,vh * 10);}
div {height: max(300,vh / 10);}';
Copy link
Contributor

Choose a reason for hiding this comment

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

For readability, can this be a series of concatenations with "\n", so that indentation is retained?

Comment on lines +1 to +12
div {
height: max(300, vh + 10);
}
div {
height: max(300, vh - 10);
}
div {
height: max(300, vh * 10);
}
div {
height: max(300, vh / 10);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd prefer valid examples here. vh is a unit not a value. 100vh is the viewport height. Though an extra test where the number is omitted wouldn't go amiss.

* @throws UnexpectedEOFException
* @throws UnexpectedTokenException
*/
public static function parseArgs(ParserState $oParserState)
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps parseArguments is a better name (though I know 'args' is a very common shorthand).

@@ -0,0 +1,3 @@
div {
height: ///!;
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice.

@JakeQZ JakeQZ requested a review from oliverklee February 15, 2024 18:16
Copy link
Contributor

@oliverklee oliverklee left a comment

Choose a reason for hiding this comment

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

Please let's move the refactoring to a separate change (either as a pre-patch, or as a post-PR cleanup). This allows us to stick to the "only one kind of change per PR/commit" rule of thumb, and also to selectively backport or revert commits.

@nickfmc
Copy link

nickfmc commented Jun 19, 2024

do we have an ETA on this one? not having the calc and clamp functions work is a huge issue in 2024

@oliverklee
Copy link
Contributor

@nickfmc How fast we progress with this PR depends on whether someone (TM) would be willing to invest time into it.

Would you be willing to create a PR (or multiple PRs) for the refactoring contained in this PR here so we get them out of the way, and then take over this PR?

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 20, 2024

I looked at rebasing this. I don't think it's possible. There have been too many changes since.

I'd like to be able to see the full diff on GitHub without the review comments, in order to re-apply the changes. But I can't find how to do that.

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 20, 2024

I'd like to be able to see the full diff on GitHub without the review comments, in order to re-apply the changes. But I can't find how to do that.

I found the '[Don't] Show Comments' option, it's on the '•••` menu, on a per-file basis. I should be able to take this on as fresh PRs, unless @nickfmc you would like to?! Thanks for the nudge :)

JakeQZ pushed a commit that referenced this pull request Jun 20, 2024
Also
- Update the `parse` function signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclass to avoid contravariance.

This is the refactoring change from #390.
JakeQZ pushed a commit that referenced this pull request Jun 20, 2024
Also
- Update the `parse` function signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

This is the refactoring change from #390.
JakeQZ pushed a commit that referenced this pull request Jun 20, 2024
Also
- Update the `parse` function signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

Unfortunately, there seems to be a bug in PHP 7.3 (and 7.2) whereby it
doesn't recognize a specific class name as a more-specific type than
`object`, even though it does recognize it as more specific than an untyped
return value.  Thus some more-specific type annotations have had to be
downgraded.

This is the refactoring change from #390.
@JakeQZ JakeQZ added this to the 8.6.0 - Critical Features milestone Jun 21, 2024
@JakeQZ JakeQZ self-assigned this Jun 21, 2024
JakeQZ pushed a commit that referenced this pull request Jun 21, 2024
JakeQZ pushed a commit that referenced this pull request Jun 21, 2024
Also
- Update the `parse` function signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

Unfortunately, there seems to be a bug in PHP 7.3 (and 7.2) whereby it
doesn't recognize a specific class name as a more-specific type than
`object`, even though it does recognize it as more specific than an untyped
return value.  Thus some more-specific type annotations have had to be
downgraded.

This is the refactoring change from #390.
JakeQZ pushed a commit that referenced this pull request Jun 21, 2024
Also
- Update the `parse` function signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

Unfortunately, there seems to be a bug in PHP 7.3 (and 7.2) whereby it
doesn't recognize a specific class name as a more-specific type than
`object`, even though it does recognize it as more specific than an untyped
return value.  Thus some more-specific type annotations have had to be
downgraded.

This is the refactoring change from #390.
JakeQZ pushed a commit that referenced this pull request Jun 21, 2024
Also
- Update the `parse` function signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

This is the refactoring change from #390.
JakeQZ pushed a commit that referenced this pull request Jun 21, 2024
Also
- Update the `parse` method signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

This is the refactoring change from #390.
@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 21, 2024

do we have an ETA on this one? not having the calc and clamp functions work is a huge issue in 2024

Upon checking, I find that calc is already parsed correctly. clamp I'm not so sure about - calc is specifically handled including with vendor prefixes. Constructs like max(300px, 50vw + 10px) definitely fail at present.

oliverklee pushed a commit that referenced this pull request Jun 22, 2024
)

Also
- Update the `parse` method signature to use PHP7 type hints;
- Remove subsequently redundant DocBlock entries;
- Ditto for same-named method in subclasses to avoid contravariance.

This is the refactoring change from #390.

Co-authored-by: Jake Hotson <[email protected]>
@oliverklee
Copy link
Contributor

This PR now needs a rebase.

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 22, 2024

This PR now needs a rebase.

I already looked at rebasing, but it seemed a bit of a nightmare with the number of changes since, particularly given I'd be working on someone else's fork, and that in any case we wanted to split this up into three more atomic changes. So I am reimplementing the changes from here as fresh PRs: #599, #607, and the infinite loop fix TBD.

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 26, 2024

Reopening, as there's still the infinite loop bugfix from this to be applied.

@oliverklee oliverklee reopened this Jun 26, 2024
@nickfmc
Copy link

nickfmc commented Jun 26, 2024

Does this ticket address the lack of CSS feature clamp working correctly? Or do we need a new ticket for that?
font-size: clamp(2.19rem,0.5vw + 2.06rem,2.5rem);

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 26, 2024

Does this ticket address the lack of CSS feature clamp working correctly? Or do we need a new ticket for that? font-size: clamp(2.19rem,0.5vw + 2.06rem,2.5rem);

I'll add a test for that and get back to you...

@JakeQZ JakeQZ mentioned this pull request Jun 26, 2024
@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 26, 2024

Does this ticket address the lack of CSS feature clamp working correctly? Or do we need a new ticket for that? font-size: clamp(2.19rem,0.5vw + 2.06rem,2.5rem);

I'll add a test for that and get back to you...

Good news. Yes, it does. Or at least I'm 99.99% sure - I extended the test previously added to include clamp; the exact expression tested in the 2nd argument doesn't quite match yours (and doesn't include an rem value), but I can't think of any reason why your specific example could fail whilst the expression used in the test works. See #620.

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 26, 2024

Good news. Yes, it does. Or at least I'm 99.99% sure - I extended the test previously added to include clamp; the exact expression tested in the 2nd argument doesn't quite match yours (and doesn't include an rem value), but I can't think of any reason why your specific example could fail whilst the expression used in the test works. See #620.

PS. What may still not work is expressions involving brackets, like (1rem + 1vw) * 2, though I don't honestly know at time of writing.

@nickfmc, would you be able to try the 9.0.x-dev branch to confirm this fixes the clamp issue for you, and let us know if you find any other issues? Thanks.

@JakeQZ
Copy link
Contributor

JakeQZ commented Jun 27, 2024

Reopening, as there's still the infinite loop bugfix from this to be applied.

Upon investigation, I find the infinite loop bug was subsequently fixed by #413. Since we want to move away from having test data in separate files, I am not going to include the additional test for this as it is. I looked at adding a more targeted test, and found a curious behaviour, which I logged as #622. Thus, I am re-closing this in favour of that.

@JakeQZ JakeQZ closed this Jun 27, 2024
JakeQZ added a commit that referenced this pull request Jun 28, 2024
This is the enhancement from #390.

`calc` was already supported.
JakeQZ added a commit that referenced this pull request Jun 29, 2024
This is the enhancement from #390.

`calc` was already supported.
oliverklee pushed a commit that referenced this pull request Jun 30, 2024
This is the enhancement from #390.

`calc` was already supported.

Co-authored-by: Jake Hotson <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants