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

Missing public OutputType #270

Open
swiftyfinch opened this issue Mar 15, 2024 · 5 comments
Open

Missing public OutputType #270

swiftyfinch opened this issue Mar 15, 2024 · 5 comments

Comments

@swiftyfinch
Copy link
Contributor

Hello @cpisciotta!
Firstly, I have been using xcbeautify for many years and I absolutely love it!

I noticed that you have restricted the visibility of OutputType from public to package.
swiftyfinch/Rugby#366

This was important for my project as it allowed me to:

Could we please open it again?

@cpisciotta
Copy link
Owner

Hi @swiftyfinch.

Thanks for being an xcbeautify user, and sorry for the delayed response!

I internalized OutputType, since I wanted this to be an implementation detail, similar to most of the other types.

In the future, my intention has been to simply read a string and output an optional (formatted) string via Xcbeauitier.

Recently, I introduced a protocol called OutputRendering. Its concrete types are meant to be custom formatters, and I think that might address your use case.

Have you looked into this, and what do you think about creating one to solve this issue?

I’d like to avoid re-exposing other types as public, since it’ll slow down some of the otherwise breaking changes I’ve been planning to make, but I’m open to other ideas.

Let me know what you think, and we can find a way to continue supporting your use case.

@swiftyfinch
Copy link
Contributor Author

@cpisciotta I'm sorry, I'm not sure I understand what you mean.
Do you want to open OutputRendering protocol?

If so, it would look like this:

public protocol OutputRendering { ... }

public enum Renderer: String {
    ...

    /// Any custom render
    case custom(OutputRendering)
}

XCBeautifier(renderer: .custom(MyRender())).format(line: "something")

And then, any user can provide a custom render.
This is not as simple as just opening OutputType, but it is quite flexible.

However, there is a downside - it requires opening a lot of *Capture types and their properties in order to allow for custom renders. For example, ErrorCaptureGroup.

public protocol ErrorCaptureGroup: CaptureGroup {
    var wholeError: String { get }
}

struct MyRender: OutputRendering {
    func formatError(group: ErrorCaptureGroup) -> String {
        let errorMessage = group.wholeError
        return ... // custom implementation
    }
}

Did I understand you correctly?

@cpisciotta
Copy link
Owner

@swiftyfinch Not quite. I am asking if you'd be open to implementing a "Rugby-style" formatter directly in the xcbeautify project. It would obviously be consumed by Rugby, but because it'd be in the project, it could be used by others too.

@swiftyfinch
Copy link
Contributor Author

@cpisciotta Oh, I see.
I will give it a try when I have some free time.
Thank you for the suggestion!

@cpisciotta
Copy link
Owner

@swiftyfinch No problem! Let me know how I can help.

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

No branches or pull requests

2 participants