Hi Niels, First of all, thank you for your support!
Why did you choose UrlParser to be a "static" class? Right now it's just a > fancy namespace. That's a good question, let me explain the reason: one of my major design goals was to make the UrlParser class to be extendable and configurable (e.g. via an "engine" property similar to what Random/Randomizer has). Of course, UrlParser doesn't support any of this yet, but at least the possibility is there for followup RFCs due to the class being final. Since I knew it would be an overkill to require instantiating an UrlParser instance for a task which is stateless (URL parsing), finally I settled on using static methods for the purpose. Later, if the need arises, the static methods could be converted to non-static ones with minimal BC impact. It's a bit of a shame that the PSR interface treats queries as strings. In Javascript we have the URLSearchParams class that we can use as a > key-value storage for query parameters. Hm, yes, that's an observation I can agree with. However, this restriction shouldn't limit followups to add key-value storage support for query parameters. Although, as far as I could determine, neither Lexbor is capable of such a thing currently. Why is UrlComponent a backed enum? To be honest, it has no specific reason apart from that's what I am used to. I'm fine with whatever choice, even with getting rid of UrlComponent completely. I added the UrlParser::parseUrlComponent() method (and hence the UrlComponent enum) to the proposal in order to have a direct replacement for parse_url() when it's called with the $component parameter set, but I wasn't really sure whether this is needed at all... So I'm eager to hear any recommendations regarding this problem. A nit: We didn't bundle the entire Lexbor engine, only select parts of it. > Just thought I'd make it clear. Yes, my wording was slightly misleading. I'll clarify this in the RFC. About edge cases: e.g. what happens if I call the Url constructor and leave > every string field empty? Nothing :) The Url class in its current form can store invalid URLs. I know that URLs are generally modeled as value objects (that's also why the proposed class is immutable), and generally speaking, value objects should protect their invariants. However, due to separating the parser to its own class, I abandoned this "rule". So this is one more downside of the current API. Regards, Máté
