Add subScheme Support and Align with RFC 3986 Section 3.1 for Scheme Extraction (Fixes #2101)

[itboy87]

Add Support for subScheme in URLs

This pull request introduces the following changes:

• New Variable: Added subScheme to support URLs with subScheme.

• Regex Modification: Adjusted the scheme regex from \\w+: to ^([a-zA-Z0-9+.-]+)(?::([a-zA-Z]+))?: to align with the standard specified in RFC 3986 Section 3.1: ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) and supporting subScheme.

• Test Cases: Added new test cases to ensure proper functionality.

Example Use Cases:

• <scheme>:<subScheme>://<host>:<port>/<path>?<query_parameters>#<fragment>
• Example: jdbc:mysql://localhost:3306/database

This PR closes #2101

[soywiz]

I believe we should either create a new overload keeping the old (for compatibility), or placing the subScheme at the end to avoid people not using named arguments to have broken code

[soywiz]

Alternatively maybe we could just support subschemes by using scheme = "jdbc:mysql" and validating it somewhere else and providing subScheme and mainScheme or something like that as read-only properties?

[itboy87]

I think we should create an overload function and keep the subScheme variable.

[soywiz]

What if we create a fun fromComponents, keep the invoke as it is and mark it as deprecated? The main problem is that since we have several strings in a row and named arguments are not mandatory, this might be a compatibility problem

[itboy87]

As per my suggestion, URL(..) offers a much better and developer-friendly syntax compared to URL.fromComponents.

[soywiz]

In this case, we should at least deprecate the other signature:

But let me insist:

The problem with the invoke is probably disambiguation in some circumstances.

Also, let's consider this example:

val url2 = URL(scheme = "HTTPs", userInfo = null, host = "Google.com", path = "", query = null, fragment = null)

I would say that forcing to provide nulls for all the arguments is also not a good experience. It would be better to provide all the values as null by default, and since we have a typical URL(fullUrl: String) signature, that might be a problem.

I would say it could be better to have:

val url2 = URL.fromComponents(scheme = "HTTPs", host = "Google.com")
//
val url2 = URL.fromComponents(scheme = "jdbc",  subScheme ="mysql", host = "localhost")

No disambiguation required.

Also you can keep the current invoke, without adding the extra subScheme to the end nulled by default, so current code still works like this even if used without named arguments:

fun fromComponents(
  scheme: String? = null,
  subScheme: String? = null,
  userInfo: String? = null,
  host: String? = null,
  path: String = "",
  query: String? = null,
  fragment: String? = null,
  opaque: Boolean = false,
  port: Int = DEFAULT_PORT,
) = ...

@Deprecated(replaceWith = ReplaceWith("URL.fromComponents(scheme, subScheme, userInfo, host, path, query, fragment, opaque)"))
operator fun invoke(
  scheme: String?,
  userInfo: String?,
  host: String?,
  path: String,
  query: String?,
  fragment: String?,
  opaque: Boolean = false,
  port: Int = DEFAULT_PORT,
  subScheme: String? = null,
): URL = URL.fromComponents(scheme, subScheme, userInfo, host, path, query, fragment, opaque)

with the Deprecated, it gives people visibility to the new function. It allows providing all the arguments by default so not having to provide every argument not used as null, as there is no signature conflict with URL(String).

[itboy87]

Okay, that sounds better.

[itboy87]

I've made changes. Could you please take a look?

[soywiz]

LGTM

[soywiz]

Thansk!