Hacker News Reader

Comment by skybrian | Hacker News Reader

This library seems to be providing a framework and doesn’t include any interesting parsers. (There is no email address parser, despite the example.) It seems to allow for some composition of parsers, but the basic idea is a design pattern that’s simple enough that it doesn’t obviously require a framework.

So it seems like most of the value comes from standardizing on domain types like Username, Email, and so on. Using a framework doesn’t get you there, and it adds a dependency on the framework.

View on HN

Hi skybrian, would you mind explaining why do you see this as a framework?

About missing interesting parsers, you are right, for now only the core part is done. Based on community interest, we will work on complementary packages, like more common parsers, easy integration with a web framework like ktor, effectful parsers based on coroutine, etc...

Lots of work ahead :D

Well, it's a minimal framework. Parsers are supposed to implement a particular function definition [1] and use the "Parsed" type for their return value, which if widely adopted, will result in references to the core library's types appearing in a lot of API's.

The advantage is that you can write code using generics that works with any parser, but I'm a little skeptical about the value of generic code.

[1] https://github.com/parsix/parsix#build-your-own-parse

I see, but isn't that true for any library? xD

In the end, `Parsed` should only be handled whereever you receive the initial input, so the rest of your business logic will be free of it :)

In the end, this is just a tool and it's fine if it isn't fitting your particular style or use case ;)

Yes, there's nothing particularly wrong with it, but core types should be standardized or you end up with multiple string libraries (as in C) or multiple dependency injection libraries (as in Java). Validation libraries already exist for Java.

So if this sort of thing takes off there is likely to be a standardization process at some point.

Go works better for this because common interfaces can be implemented by "coincidence." (Structural types.)

I see and I would love for this to become a standard :D But I guess that will require quite some time and a lot of luck

Reply on news.ycombinator.com