I guess it depends on how you structure your code.
If you validate at constructor level, then you have this problem. However if you actually parse it, then this will have to be external to the actual class and you are left with a simple Value Object. This means that you can apply constraints only when it makes sense. Most of the time, there is little reason to validate something coming from the DB, so I would rather skip it.
About unboxing, that depends. I would expect for the overall business logic to always use the more structured types, probably this will only be needed once you need to serialize them :)
That's said, if you are happy with your current way, please keep doing it! I would still suggest to give this style a try though :)
Hey, I fail to see how this is suboptimal. Some points I don't understand:
* What's the goal of a validation that always succeed?
* What's the value of checking constraints after you parsed it and not capture this information?
In the end, parsing is just a combination of what you described: ensure something fit a particular shape and constraints :)
I honestly think the two arguments are different though. We could say that Postel's Maxim is about "how much you should parse/validate", while the problem we are addressing is rather "how you should do it" :)
I'm using Kotlin and still PHP in some legacy part at work, but whenever I can in my free-time I use Haskell, Elm and read about FP concepts. What about you? :)
Talking about "parsing", I see that different people have a different understanding of it. I will fix this point by writing in the README what we mean when we way "parsing" :)
Allow me to disagree with the "tracking validation using typestate" bit. This is just one way, but using Parsix you can also go from a String to a more complex type like Email(local: Local, domain: Domain), where Local and Domain can also be other complex types. The point is, you should parse as much or as little as you need in your domain. That's why we call it "general-purpose parsing" ;)
If that style works for you, please be my guest! As usual, this library is just a tool, it may or may not fit your use case, and that's fine ;)
By no means we want to pass the message that you have to use this library to benefit from the "Parse, don't validate" pattern. What we want is to make the pattern more mainstream and provide a nice set of functionalities out of the box :)
Also I would like to encourage everyone to get as much as you need from this library. If you don't like `focusedParse`, please don't use it! xD
Hey, thanks for starting this discussion, I think it will be an interesting one :)
1) Just to be clear, when I read "serialise" I understand that you want to parse some object into a format suitable for storage. I would honestly go with the common flow: use some library like kotlinx.serialization or whatever your database library support. If this isn't what you meant, please let me know.
2) I personally like well defined type. For example, if you have a case where Email must be like Email(local, domain, tld) and another where you just want a String out of your email, I would rather use two different types for the two different use cases and therefore different parsing logic (which will probably share most code, but still produce different results). On the other hand, if you want to model the fact that some piece of information could be provided or not by the external source, than yes, I would just go with nullable types, which in Kotlin is like `Something?`, but in other language are known as Maybe or Optional.
3) Just to be clear, I will strongly advice against having validation in object constructors. Once this is out of the picture, you are left with simple Value Objects: simple, immutable, bundle of data with a defined structure and semantic meaning. When you work with these simple objects, it's very easy to derive different views for whatever use case you need. I'm not familiar with SQLAlchemy and Python ecosystem in general, but I guess there will be some way of converting a specific type into one that is suitable for DB consumption.
4) Both Parse and Parsed are actually Monads ;) And we know something about Monads, is that composing different Monads together is usually not straightforward xD That's said, in your particular example of having an optional field, I would see the parser produce a Maybe<Something> (or Something? in Kotlin)
Let me know if I got you right and what you think about it :)
I see, thanks for sharing. I will improve the README by adding a clear definition for parsing, validation and deserialization, so that we can all be on the same page ;)
I see, that would be problematic indeed. I strongly believe in Bounded Contexts, a concept from Domain Driven Design. As for the Ubiquitous Language (ie: product & engineers naming things the same way, code included), parsing logic should also be segregated and specific to your domain. I would argue that you should have different parsers for different purposes even inside the same system, for example one could be applied to inputs coming from an User, while another could be applied to an API and one more when coming from a DB.
I think I would stress this point more in the README, thanks for sharing :thumbsup:
Yeah, I've also worked with weak type systems in the past too (PHP, Ruby, JS), so I can definitely share the pain! I learned the hard way how much easier it is to build complex systems when you have a compiler helping you ;)
I see, this is also an interesting approach and definitely have its usages. Thinking about it, though, it has its own limitations when it comes to scalability and business requirements naturally out from the database box, eg: how would you ensure an S3 file reference is actually valid and it does exist?
Well said! I would only like to add that I highly discourage adding validations/assertions in the actual data class, this often make them hard to work with and reuse. It is better to have this parsing logic as a simple function, perhaps at factory level if you prefer that kind of flavor :)
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...
Yes, it is basically a combination of proofing some data has been validated by encoding this proof in a specific type, like Email :)
We want to popularize this idea and make it easier to work with it by offering some nice, type-safe abstraction.