Separate types for Application and ApplicationId

[deuszx]

Motivation

We want to fix and expand our notion of Address (currently Owner, GenericApplicationId, etc.) to different type of addresses (32-byte Linera/Solana, 20-byte EVM). In order to do that we need to prepare the code for the introduction of new variants.

Proposal

Add a separate type for ApplicationId(hash) vs Application (a hash + type-safe ABI). Previously the presence of A type parameter in "address" enum made it more difficult to refactor. After this PR we have separate types for application's address and application with ABI (used mostly in tests and CLI now).

Test Plan

CI should catch regressions.

Release Plan

• Nothing to do / These changes follow the usual release cycle.

Links

• reviewer checklist

[ma2bd]

We haven't really discussed what to do with ApplicationId yet. I was hoping we don't need to change this.

[deuszx]

We haven't really discussed what to do with ApplicationId yet. I was hoping we don't need to change this.

We can discuss but I don't see what's controversial here. We keep all the security and features as before - users can use type-safe Application - it's just now the address of the application doesn't have the type parameter. In my mind that's not a regression since we were calling forget_abi() anyway (i.e. we set A = () for UserApplicationId).

[ma2bd]

Thanks for the PR.

I'd rather keep application_id: ApplicationId<A> for the SDK: Application feels a bit vague and requires a massive refactoring of variable names -- including for our SDK users.

Why not use UserApplicationId for the (internal) use case without a type parameter?

[ma2bd]

This PR ruins the field/variable naming convention in many places.

[deuszx]

See #3582 for alternative.

[deuszx]

I'd rather keep application_id: ApplicationId<A> for the SDK: Application feels a bit vague and requires a massive refactoring of variable names -- including for our SDK users.

In my mind *Id is just for identification and so the ApplicationId<A: Abi> whose purpose (and difference compared to ApplicationId<()>) was to convey the underlying application's ABI did not seem fit that as the additional Abi type provided information about the application that goes beyond its address.

Why not use UserApplicationId for the (internal) use case without a type parameter?

What does the User* prefix stand for? An application without the typed ABI (ApplicationId<()>) becomes a User* one when we erase it (the ABI). The same application (the same underlying address) is either an application (when the ABI is typed - ApplicationId<A>) and user application (when it's not typed - ApplicationId<()>). I can use UserApplicationId for the untyped struct but this comment would be valid still.

[deuszx]

Closing this in favor of #3582 which has far fewer changes (avoids client-facing renames).