Possible/recommended to write helper function for *pchar?

Hi,

*pchar is required for several parts, such as “query”, “reg-name”, “path” etc. There seem to be many possible combinations of scenarios/values for *pchar. Hence, I was wondering whether it is possible somehow to write a helper function checking whether some input is a *pchar or not, similar to the isIPv4Address helper function. I’m aware that there is an interface IPv4Address and no interface for *pchar, but would it nonetheless be feasible or recommended?

The easiest way to handle pchar (and in fact the entire parser) is to use regex (using java.util.regex.Pattern). Once you have created a regex String r that can recognize a pchar you can embed it in a bigger regex using the String.format method like this for example:

String biggerRegex = String.format("...%s...", r)

Of course you can also write functions by hand, however reinventing the wheel is only worth it if you already know better than the guy who invented the wheel. :grinning:

3 Likes

Thanks for your reply! I noticed that I didn’t mention it in my question for some reason, but I was actually wondering about whether it would be possible to have a helper function “is *pchar or not” for the tests that we have to write (not the parser)? What I was thinking of is to collect all needed test cases for *pchar in one “helper function”, which we can then use in other tests, f.e. for “path” or for “query” etc.?
I haven’t really looked into the parser yet, so I will read your answer again when I get to the parser :grinning:

That is of course possible, but I don’t get why you want to verify that anything is a pchar in the tests anyway. You can call the UriParserFactory with an input of your choice. So you could define the different token strings (e.g. scheme, userinfo, etc.) beforehand, feed a combination of them into the UriParserFactory and call parse on it. Then you only need to call the getters for those tokens and compare them to your building blocks. This way you control what goes in and if it doesn’t match what comes out you found a bug (in the tests or the implementations).

You can create new folders and .java files in the tests folder and use those to organize your tests. Any other approach leads to chaos quickly.