Cleanup fURL method functionality/naming about flourish-classes

[mattsah]

If you're looking towards method cleanup in general, can I also add that I would like to see fURL as instantiable and able to modify (as it can with the current URL) a particular URL...

I'm not sure how you would go about cleanly maintaining backwards compatibility and not have more confusing methods, but it would be nice if I could create a URL object with any URL I want and use replaceInQueryString() and removeFromQueryString() or equivalents.

[mattsah]

Also, if the plan would be to have parts, might I suggest piggybacking the PHP parse_url constants?

fURL::get('http://www.example.com:8080/whatever/test?q=answer')->parse(PHP_URL_PORT);
fURL::get('http://www.example.com:8080/whatever/test?q=answer')->replaceInQuery('q', 'new_answer');

Similar to fDate() these objects could be immutable, so the methods always return new instances with differing internal states... the __toString() could always return the full URL, calling fURL::get() without a parameter would create an fURL object of the current URL. Idea being, if I pass fURL::get() to a method that takes a string, the __toString() method should be invoked, maintaining some if not all backwards compatibility.

Oh, and lastly, any ORM registered URL columns for validation, etc, could return fURL objects. Could even keep things consistent with a prepare() method, perhaps that could replaced %tokens with values. $url->prepare('%s%d%p/%r?%q') [scheme, domain, port, request, query]