Skip to content

Total conversion functions' conventions #74

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

carbolymer
Copy link
Collaborator

No description provided.

@carbolymer carbolymer self-assigned this May 7, 2025
@carbolymer carbolymer force-pushed the mgalazyn/adr-use-inject-for-conversion-functions branch 3 times, most recently from 8fd1aea to 1585086 Compare May 21, 2025 12:59
@carbolymer carbolymer changed the title Use Inject draft Total conversion functions naming convention May 21, 2025
@carbolymer carbolymer changed the title Total conversion functions naming convention Total conversion functions' naming convention May 21, 2025
@carbolymer carbolymer changed the title Total conversion functions' naming convention Total conversion functions' conventions May 21, 2025
@carbolymer carbolymer marked this pull request as ready for review May 21, 2025 13:00
@carbolymer carbolymer force-pushed the mgalazyn/adr-use-inject-for-conversion-functions branch 4 times, most recently from 00c20de to 3444bbf Compare May 21, 2025 13:05
@carbolymer carbolymer force-pushed the mgalazyn/adr-use-inject-for-conversion-functions branch 2 times, most recently from d39cbda to ea7ef24 Compare May 27, 2025 10:10
@carbolymer carbolymer requested a review from newhoggy May 27, 2025 10:11
@carbolymer carbolymer force-pushed the mgalazyn/adr-use-inject-for-conversion-functions branch 2 times, most recently from d3d3831 to 756aef0 Compare May 27, 2025 12:31
Copy link
Collaborator

@Jimbo4350 Jimbo4350 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but left two comments.

@carbolymer carbolymer force-pushed the mgalazyn/adr-use-inject-for-conversion-functions branch 2 times, most recently from 5631f68 to c9e8e94 Compare May 27, 2025 12:46
@carbolymer carbolymer force-pushed the mgalazyn/adr-use-inject-for-conversion-functions branch from c9e8e94 to 31dd2a8 Compare May 27, 2025 13:28
Copy link
Collaborator

@palas palas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Looks good to me. I added a few suggestions and questions, mainly just for clarity


# Context

In `cardano-api` we have multiple functions performing conversions between one value of the type to the other, for example:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In `cardano-api` we have multiple functions performing conversions between one value of the type to the other, for example:
In `cardano-api` we have multiple functions for performing conversions on values from one type to another, for example:


The use of those conversion functions should be limited to **internal use only**.
The library should still export conversion functions with explicit type names for better readability.
An exception to this would be a set of types which are convertible one to the other, like `Eon`s.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
An exception to this would be a set of types which are convertible one to the other, like `Eon`s.
An exception to this would be a set of types which are all convertible to each other, like `Eon`s.

I am guessing the all from the N times N below

The use of those conversion functions should be limited to **internal use only**.
The library should still export conversion functions with explicit type names for better readability.
An exception to this would be a set of types which are convertible one to the other, like `Eon`s.
Writing $N \times N$ conversion functions for $N$ types would be cumbersome and using `inject`/`convert` instead is justified here.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Writing $N \times N$ conversion functions for $N$ types would be cumbersome and using `inject`/`convert` instead is justified here.
Writing $N \times N$ conversion functions for $N$ types would be cumbersome, so using `inject`/`convert` instead is justified here.

Because it is a consequence, so this would be more precise

An exception to this would be a set of types which are convertible one to the other, like `Eon`s.
Writing $N \times N$ conversion functions for $N$ types would be cumbersome and using `inject`/`convert` instead is justified here.

Inject instances should be placed near one of the types definition, to make them more discoverable and avoid orphaned instances.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Inject instances should be placed near one of the types definition, to make them more discoverable and avoid orphaned instances.
Inject instances should be placed near the definition of one of the types, to make them more discoverable and avoid orphaned instances.

I think types definition is grammatically incorrect here, it could also be types' definition, for example, but it is less clear

Inject instances should be placed near one of the types definition, to make them more discoverable and avoid orphaned instances.

>[!NOTE]
>The difference between `Inject` and `Convert` class is that `Convert` is better typed for types with `Type -> Type` kind.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I was just asking myself this


### Injection law

The `Inject` and `Convert` classes are meant to be used for trivial conversions only and not for more complex types like polymorphic collections (e.g. `Set a`).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would be the conversion from and to in this example? Set a to what, for example? Or do you mean from one Set to another?

```haskell
import Data.Foo qualified as Foo

Foo.fromBar bar
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about toBar? Are we discouraging that? (Just asking, I don't have an opinion)

- Less maintenance burden with regards to the naming conventions of the conversion functions

## Disadvantages
- It may be a bit surprising how to discover available conversions, because one would have to browse the type's `Inject` instances to find the conversion functions they are looking for - instead of looking for exported functions.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- It may be a bit surprising how to discover available conversions, because one would have to browse the type's `Inject` instances to find the conversion functions they are looking for - instead of looking for exported functions.
- It may be a bit less obvious how to discover available conversions, because one would have to browse the type's `Inject` instances to find the conversion functions they are looking for - instead of looking for exported functions.

?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants