use a sealed class for Feed to support a dynamic 'other' option

[mmoghaddam385]

Experimenting with how it would look to use a sealed class instead of an enum for Feed. This would let us support a dynamic "other" attribute to make the SDK more flexible for when we add new feed types. I see this benefit as two-fold:

1. If we don't update our SDK to include a new Feed type right away, users can still use this SDK with it
2. If users don't want to spend the time to update the SDK version they're using but still want to use a new feed, they have that option.

If we like this pattern, we should do the same for the Market enum.

The only downside to this is that the Java interaction becomes a bit more awkward, since Java usages must access the "enum" through the .INSTANCE member as shown in the updated Java sample. LMK what you think about this tradeoff.

[justinpolygon]

Hey @mmoghaddam385,

We might be able to add a custom option to the Feed and Market enum classes, and then create a constructor for the PolygonWebSocketClient class that takes in these custom options.

For example, add a custom feed option in the Feed enum:

enum class Feed(val url: String) {
    // ...
    CustomFeed("customfeed"), // Define custom feed
}

Then, add a custom constructor in the PolygonWebSocketClient class that takes the custom URL and assigns it to the custom feed option:

class PolygonWebSocketClient(
    // ... existing parameters
    private val customFeedURL: String? = null // Add a custom feed URL parameter
) {
    init {
        // If customFeedURL is provided, update the URL of CustomFeed
        customFeedURL?.let {
            Feed.CustomFeed.url = it
        }
    }

    // ... rest of the code
}

On the cliet side, we can then create an instance with a custom feed URL like this:

val client = PolygonWebSocketClient(
    apiKey = "XXXX",
    feed = Feed.CustomFeed, // Use the custom feed
    customFeedURL = "localhost" // Set the custom feed URL to localhost
    // ... 
)

So, for example, say that you wanted to connect to a custom URL, maybe "localhost", you could do that by setting the custom feed option.

This seems to work into the existing model but if we come out with something totally new then they are going to need to message parser and model updates too. So, this only works in really limited based on the Feed side where you might want to test an alternative host.

[mmoghaddam385]

Hey @mmoghaddam385,

We might be able to add a custom option to the Feed and Market enum classes, and then create a constructor for the PolygonWebSocketClient class that takes in these custom options.

For example, add a custom feed option in the Feed enum:

enum class Feed(val url: String) {
    // ...
    CustomFeed("customfeed"), // Define custom feed
}

Then, add a custom constructor in the PolygonWebSocketClient class that takes the custom URL and assigns it to the custom feed option:

class PolygonWebSocketClient(
    // ... existing parameters
    private val customFeedURL: String? = null // Add a custom feed URL parameter
) {
    init {
        // If customFeedURL is provided, update the URL of CustomFeed
        customFeedURL?.let {
            Feed.CustomFeed.url = it
        }
    }

    // ... rest of the code
}

On the cliet side, we can then create an instance with a custom feed URL like this:

val client = PolygonWebSocketClient(
    apiKey = "XXXX",
    feed = Feed.CustomFeed, // Use the custom feed
    customFeedURL = "localhost" // Set the custom feed URL to localhost
    // ... 
)

So, for example, say that you wanted to connect to a custom URL, maybe "localhost", you could do that by setting the custom feed option.

This seems to work into the existing model but if we come out with something totally new then they are going to need to message parser and model updates too. So, this only works in really limited based on the Feed side where you might want to test an alternative host.

Hmm I think there are a couple problems with a custom enum approach. Since the enum is global you wouldn't be able to have two custom feed connections running in the same app. Maybe not a common situation but if someone tried to do it they would see some confusing behavior. I also think having a second param that overrides an existing one can be a confusing UX, particularly if we end up with two of them (one for Market another for Feed).

If we use sealed classes like in this PR I don't think we need to change anything in the message parsers, the same when statements work, and they already have default branches such that we parse an unknown message as RawMessage. You're right we wouldn't be able to use our models but if someone needs a custom feed it probably means we don't support the models yet anyways. I'm not really considering Polygon developers using localhost as a use-case.

[justinpolygon]

Makes sense to me. Fixed in #122.

[justinpolygon]

Closing this in favour of #122.