Skip to content

Conversation

@oliverklee
Copy link
Collaborator

No description provided.

@coveralls
Copy link

coveralls commented Feb 2, 2025

Coverage Status

coverage: 49.156% (+3.5%) from 45.629%
when pulling ec1aa5a on feature/property-accessors
into 7a12457 on main.

@oliverklee oliverklee force-pushed the feature/property-accessors branch 4 times, most recently from 80236b4 to 65afd70 Compare February 3, 2025 10:42
@oliverklee oliverklee changed the title [FEATURE] Add dedicated accessors for OutputFormat [FEATURE] Add dedicated property accessors for OutputFormat Feb 6, 2025
@oliverklee oliverklee force-pushed the feature/property-accessors branch from 65afd70 to d7d4a44 Compare February 6, 2025 16:29
@oliverklee oliverklee marked this pull request as ready for review February 6, 2025 16:29
@oliverklee oliverklee force-pushed the feature/property-accessors branch from d7d4a44 to 456e4d5 Compare February 6, 2025 16:31
Copy link
Collaborator

@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.

Hot on the heels of #880. Looks good, but

  • Some parameter names seem to be inaccurate;
  • The test of the deprecated array|string functionality shouldn't be changed;
  • I'm wondering if any or all of the private properties should or shouldn't have accessors (but am unsure).

Comment on lines 446 to 448
public function setBeforeAtRuleBlock(string $whitespace): self
{
$this->sBeforeAtRuleBlock = $whitespace;
Copy link
Collaborator

Choose a reason for hiding this comment

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

The property description says: "Content injected in and around at-rule blocks." Which suggests it's not necessarily whitespace, and thus the parameter should be differently named.

Comment on lines 464 to 466
public function setAfterAtRuleBlock(string $whitespace): self
{
$this->sAfterAtRuleBlock = $whitespace;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ditto.

Comment on lines 540 to 542
public function setSpaceBeforeListArgumentSeparators(array $separators): self
{
$this->aSpaceBeforeListArgumentSeparators = $separators;
Copy link
Collaborator

Choose a reason for hiding this comment

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

The separators are the array keys. The values are the space strings. So the parameter name is inaccurate.

In #880 I used $spaceForSeparator as a variable for the array, but am now wondering if one or both nouns should be plural. And I'm also wondering whether setSpaceBeforeListArgumentSeparators() was the best choice of name for the new method, though can't think of anything better.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I've changed it. Please have a look.

Copy link
Collaborator

Choose a reason for hiding this comment

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

WFM :)

Comment on lines 580 to 586
public function setSpaceAfterListArgumentSeparators(array $separators): self
{
$this->aSpaceAfterListArgumentSeparators = $separators;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ditto.

Comment on lines 616 to 622
public function setBeforeDeclarationBlock(string $whitespace): self
{
$this->sBeforeDeclarationBlock = $whitespace;
Copy link
Collaborator

Choose a reason for hiding this comment

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

The DocBlock for the property says: "Content injected in and around declaration blocks." Which implies it's not necessarily whitespace. (Also, it's not a setSpace... method.)

Comment on lines 634 to 640
public function setAfterDeclarationBlockSelectors(string $whitespace): self
{
$this->sAfterDeclarationBlockSelectors = $whitespace;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ditto.

Comment on lines 652 to 658
public function setAfterDeclarationBlock(string $whitespace): self
{
$this->sAfterDeclarationBlock = $whitespace;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Ditto.

Comment on lines 670 to 672
public function setIndentation(string $sIndentation): self
{
$this->sIndentation = $sIndentation;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Perhaps avoid the Hungarian notation in the parameter name.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Done.

Comment on lines 721 to 733
/**
* @return $this fluent interface
*/
public function setIndentationLevel(int $indentationLevel): self
{
$this->iIndentationLevel = $indentationLevel;

return $this;
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I just noticed that the $oFormatter, $oNextLevelFormat and $iIndentationLevel properties are private (whereas the others are all public), so I'm wondering whether they are intended to be accessed externally. Though currently they all can be via the generic get and set methods.

The OutputFormatter class uses getIndentationLevel(), so that at least is required (but maybe the corresponding setter isn't).

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'd like to make all properties private anyway.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I'd like to make all properties private anyway.

Agree. We can mark them @deprecated to be made private in 9.0, with a message to use the relevant accessor methods. (And when they're made private, the Hungarian notation can be dropped.)

'.main, .test {font: italic normal bold 16px/1.2 "Helvetica", Verdana, sans-serif;background: white;}'
. "\n@media screen {.main {background-size: 100% 100%;font-size: 1.3em;background-color: #fff;}}",
$this->document->render(OutputFormat::create()->setSpaceAfterListArgumentSeparator([
$this->document->render(OutputFormat::create()->setSpaceAfterListArgumentSeparators([
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is intended to test the deprecated functionality, to confirm it still works, and should not be changed. When the deprecated functionality is removed, this test method can also be removed. (Incidentally, with the new functionality, the plural method does not support the first array item being the default - the default is instead set by the existing method with a string parameter. This doesn't make a difference here since the spacing for all separators used in the test has been specified explicitly.)

Copy link
Collaborator 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
Collaborator Author

I'm wondering if any or all of the private properties should or shouldn't have accessors (but am unsure).

The goal of this PR is to replace the magic getters/setters, which means keeping the same level of access to (or encapsulation of) the OutputFormat properties. I'd like to keep the properties as encapsulated as possible. So, IMHO, they shouldn't have accessors.

As far as our test coverage goes, we currently don't need any additional accessors to the OutputFormat properties.

@oliverklee oliverklee force-pushed the feature/property-accessors branch from 456e4d5 to c566b31 Compare February 6, 2025 21:16
@JakeQZ
Copy link
Collaborator

JakeQZ commented Feb 6, 2025

I'm wondering if any or all of the private properties should or shouldn't have accessors (but am unsure).

The goal of this PR is to replace the magic getters/setters, which means keeping the same level of access to (or encapsulation of) the OutputFormat properties. I'd like to keep the properties as encapsulated as possible. So, IMHO, they shouldn't have accessors.

That was my thinking. Though the private $iIndentationLevel needed a 'getter' for the OutputFormatter class. Beyond the scope of this PR, but I wondered on the preceding basis if it really needed a 'setter' as well.

@oliverklee oliverklee force-pushed the feature/property-accessors branch from c566b31 to 5d53656 Compare February 6, 2025 22:32
@oliverklee oliverklee requested a review from JakeQZ February 6, 2025 22:32
@oliverklee
Copy link
Collaborator Author

Though the private $iIndentationLevel needed a 'getter' for the OutputFormatter class. Beyond the scope of this PR, but I wondered on the preceding basis if it really needed a 'setter' as well.

So far, the setter only used in tests. So I think we could indeed drop it again. What do you think?

@oliverklee
Copy link
Collaborator Author

Removed setIndentationLevel and repushed.

@JakeQZ JakeQZ merged commit 88b8729 into main Feb 6, 2025
21 checks passed
@JakeQZ JakeQZ deleted the feature/property-accessors branch February 6, 2025 22:41
@JakeQZ
Copy link
Collaborator

JakeQZ commented Feb 6, 2025

Though the private $iIndentationLevel needed a 'getter' for the OutputFormatter class. Beyond the scope of this PR, but I wondered on the preceding basis if it really needed a 'setter' as well.

So far, the setter only used in tests. So I think we could indeed drop it again. What do you think?

I could be wrong, but I don't think it's needed in the public API - it's for internal use rendering nested items.

We'll need to adjust (or remove) the test which uses it though.

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.

3 participants