Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce covariant types ino fa-db #17

Open
benedeki opened this issue Mar 4, 2022 · 2 comments
Open

Introduce covariant types ino fa-db #17

benedeki opened this issue Mar 4, 2022 · 2 comments
Labels
enhancement New feature or request help wanted Extra attention is needed under discussion Requires consideration before a decision is made whether/how to implement

Comments

@benedeki
Copy link
Contributor

benedeki commented Mar 4, 2022

Background

Many core fa-db classes are type parametrized, using invariant types.

Feature

It might be needed for better flexibility to introduce covariants, for example in DBExecutor[E]

@benedeki benedeki added enhancement New feature or request help wanted Extra attention is needed priority: low under discussion Requires consideration before a decision is made whether/how to implement labels Mar 4, 2022
@benedeki benedeki moved this from 🆕 To groom to 📋 Backlog in CPS small repos project Jun 9, 2023
@salamonpavel
Copy link
Contributor

In Scala, variance annotations (+T, -T) are used to express how types with a certain type parameter relate to each other when the type parameter is a subtype or supertype of another type. This is useful for collections and function types, among others.

However, when it comes to SQL queries modeled as Scala classes, variance doesn't make much sense. Here's why:

  1. Queries are not collections: Variance is often used with collections, where it's useful to be able to treat a List[Dog] as a List[Animal] if Dog is a subtype of Animal. But a SQL query is not a collection. It's a description of an operation to be performed on the database.

  2. Queries don't have subtypes: In a SQL query modeled as a Scala class, the type parameter typically represents the type of the data returned by the query. But one query doesn't subtype another query. Each query is a distinct operation with its own return type.

  3. Queries are invariant in their result type: The result type of a query is fixed. If a query returns rows of type Dog, you can't use it as if it returned rows of type Animal or Poodle. You have to write a different query to get rows of a different type.

So, in the context of SQL queries modeled as Scala classes, variance annotations would not provide any benefit and could potentially lead to incorrect code if they were allowed.

@salamonpavel
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed under discussion Requires consideration before a decision is made whether/how to implement
Projects
Status: 📋 Backlog
Development

No branches or pull requests

2 participants