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

[TASK] Mark parsing-internal classes and methods as @internal #674

Merged
merged 2 commits into from
Sep 5, 2024

Conversation

oliverklee
Copy link
Contributor

Code that uses this library is not expected to call internal parsing functionality. Communicate this with the corresponding @internal annotation.

This allows us to boldly refactor the parser code.

Part of #668

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.

Anchor and ParserState both look internal to me, so marking those as internal seems fine.

I'm not sure if the exception class hierarchy should be internal.

The Parser::get/setCharset methods are part of the current interface (and not actually used internally). If we want to remove them (I'm not sure), we should mark them as deprecated.

@sabberworm, what are your thoughts on these?

I thought the plan to mark methods as deprecated required the logger interface to be in place first, so that users can be informed if they are calling deprecated methods. So if we do want to deprecate the charset get/set methods, that part of this PR would have to be put on hold.

src/Parser.php Outdated
Comment on lines 33 to 41
* Sets the charset to be used if the CSS does not contain an `@charset` declaration.
*
* @param string $sCharset
*
* @internal
*/
public function setCharset($sCharset): void
Copy link
Contributor

Choose a reason for hiding this comment

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

The description suggests that this is not an internal method. However, the example in the readme shows setting the charset via Settings::withDefaultCharset(). But searching the code base, I find this is not actually called internally (internally we set the charset directly on the ParserState object).

So if we don't want to expose this method moving forwards, we should mark it as deprecated. In which case, we want the logger inferface implementation before we can do so, don't we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They are now deprecated (#688) instead.

Comment on lines 6 to 10
* Thrown if the CSS parser attempts to print something invalid.
*
* @internal
*/
class OutputException extends SourceException
Copy link
Contributor

Choose a reason for hiding this comment

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

This is thrown on attempting to render a declaration block whose selector(s) have all been removed. There's a test specifically for that situation and behaviour (with or without the 'throw exceptions' setting), so this doesn't look internal to me.

The same applies to the entire exception hierarchy. Though I don't see a reason not to make them internal moving forwards..

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

@oliverklee
Copy link
Contributor Author

oliverklee commented Aug 27, 2024

So if we don't want to expose this method moving forwards, we should mark it as deprecated. In which case, we want the logger inferface implementation before we can do so, don't we?

No, I don't think that not having the logger should be a blocker for deprecating things.

@oliverklee
Copy link
Contributor Author

The Parser::get/setCharset methods are part of the current interface (and not actually used internally). If we want to remove them (I'm not sure), we should mark them as deprecated.

I have now created #688 to deprecate them.

@oliverklee oliverklee marked this pull request as draft August 28, 2024 22:05
Code that uses this library is not expected to call internal parsing
functionality. Communicate this with the corresponding `@internal`
annotation.

This allows us to boldly refactor the parser code.

Part of #668
@oliverklee
Copy link
Contributor Author

Updated and repushed.

@JakeQZ
Copy link
Contributor

JakeQZ commented Sep 5, 2024

This is still marked as 'Draft'.

@oliverklee oliverklee marked this pull request as ready for review September 5, 2024 15:50
@oliverklee
Copy link
Contributor Author

This is still marked as 'Draft'.

Oops, thanks - not anymore! 😉

@oliverklee oliverklee merged commit 707b5cb into main Sep 5, 2024
21 checks passed
@oliverklee oliverklee deleted the task/internal-parser branch September 5, 2024 16:01
oliverklee added a commit that referenced this pull request Sep 5, 2024
Code that uses this library is not expected to call internal parsing
functionality. Communicate this with the corresponding `@internal`
annotation.

This allows us to boldly refactor the parser code.

This is the backport of #674.

Part of #668
JakeQZ pushed a commit that referenced this pull request Sep 5, 2024
Code that uses this library is not expected to call internal parsing
functionality. Communicate this with the corresponding `@internal`
annotation.

This allows us to boldly refactor the parser code.

This is the backport of #674.

Part of #668
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.

2 participants