dmfs / uri-toolkit Goto Github PK

WwwFormUrlEncoded uses %20 to encode spaces when it should use "+".
Also it doesn't normalize new line sequences.

In order to generate a Parametrized instance (to build a Query or a Fragment), as a developer, I want a Parametrized adapter class that takes a list of Pairs.

The idea is to be able to create a Parametrized like so:

Param<CharSequence> p = new TextParam("query");
Param<Integer> c = new IntegerParam("count");

Parametrized<UriEncoded, UriEncoded> params =
    new ParametrizedPairs(p.param("query value"), c.param(1234));

which would result in a query like query=query+value&count=1234.

In order to create geo URIs in a convenient manner, as a user of this library, I wand a GeoUri class that represents a geo URI as per RFC5870.

At present we have no GeoLocation object so we should go with constructors like

   GeoUri(double coordA, double coordB, double coordC, CharSequence crs, double uncertainty); 
   GeoUri(double coordA, double coordB); 
   GeoUri(double coordA, double coordB, double uncertainty); 

The Optional interface now has its own project at dmfs/optional.

This constructor is currently missing.

Java 21 has a new String Template feature in preview. This could serve as the basis to generate URIs from URI templates or something alike

In order to be able to check Uris (and their components) for equality and put them into Sets or use them as keys in a Map, as a developer I want proper support for equals(Object) and hashCode().

Before we can approach this we need to define the correct behavior. For instance as per RFC 3986, two URIs are considered to represent the same resource if their normalized forms are equal. What does this mean with respect to equals(Object)? Should we normalize the Uris before we compare them or do we leave that to the developer?

In general this could potentially result in a lot of duplicate code, if every implementation has its own equals(Object) and hashCode() methods. So the idea is to create decorators or adapters that add the ability to use equals(Object) and hashCode(). Something like new Hashable(uri) or new Equalable(uri). However since all other objects still have a default implementation of these methods a developer could easily do it wrong without noticing. The current idea to handle this is to throw an UnsupportedOperationException in equals(Object) and hashCode() of objects which do not support hashing and comparison. The behavior would be similar to adding non-hashable objects to a set in Python. This could be achieved by inheriting from an abstract base object class.

See comment at:
schedjoules/android-event-discovery-sdk#331 (comment)

public final class JavaUri implements Uri
{
    private final Uri mDelegate;


    public JavaUri(URI javaNetUri)
    {
        mDelegate = new LazyUri(new Precoded(javaNetUri.toString()));
    }

... delegations

javaNetUri.toString() could be replace with new ToStringCharSequence(javaNetUri) where ToStringCharSequence takes any Object and delegates to toString() string lazily.

Maybe remove direct dependency for iterators as optional uses it anyway.