This is somewhat quirky. An alternative solution to this problem is to require any references from a constraint to be const. This is just like how classes work. However, this solution would limit the usefulness of typealiases.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/apple/pkl/pull/510
**Author:** [@bioball](https://github.com/bioball)
**Created:** 5/30/2024
**Status:** ❌ Closed
**Base:** `main` ← **Head:** `typealias-late-binding`
---
### 📝 Commits (1)
- [`5900247`](https://github.com/apple/pkl/commit/59002471a1aef67bdd91d5cf397f94c612516c8a) Restore late-binding for constraints within typealiases
### 📊 Changes
**12 files changed** (+92 additions, -7 deletions)
<details>
<summary>View changed files</summary>
📝 `pkl-core/src/main/java/org/pkl/core/ast/type/ResolveQualifiedDeclaredTypeNode.java` (+2 -1)
📝 `pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java` (+11 -4)
📝 `pkl-core/src/main/java/org/pkl/core/ast/type/UnresolvedTypeNode.java` (+20 -2)
📝 `pkl-core/src/main/java/org/pkl/core/runtime/VmTyped.java` (+10 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule2.pkl` (+3 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule3.pkl` (+3 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint3.pkl` (+25 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint4.pkl` (+5 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule2.pcf` (+1 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule3.pcf` (+1 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint3.pcf` (+9 -0)
➕ `pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint4.pcf` (+2 -0)
</details>
### 📄 Description
This is one proposal to fix https://github.com/apple/pkl/issues/446.
This changes the behavior of typealiases such that:
* If the current frame's receiver is amending the typealias's declared module, set the constraint to the current receiver.
* Otherwise, set it to either the receiver of a qualified type declaration, or the typealias's enclosing receiver.
This implies that the meaning of a typealias can change depending on where it is resolved from. Given the following:
```groovy
// module1.pkl
typealias MyTypeAlias = Any(isValid)
isValid = false
```
```groovy
// module2.pkl
amends "module1.pkl"
isValid = true
```
These two properties have different type checks:
```groovy
import "module1.pkl"
import "module2.pkl"
propA: module1.MyTypeAlias // always fails
propB: module2.MyTypeAlias // always passes
```
Despite this, they are considered the same typealias.
```groovy
import "module1.pkl"
import "module2.pkl"
res = module1.MyTypeAlias == module2.MyTypeAlias // true
```
This is somewhat quirky. An alternative solution to this problem is to require any references from a constraint to be `const`. This is just like how classes work. However, this solution would limit the usefulness of typealiases.
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/apple/pkl/pull/510
Author: @bioball
Created: 5/30/2024
Status: ❌ Closed
Base:
main← Head:typealias-late-binding📝 Commits (1)
5900247Restore late-binding for constraints within typealiases📊 Changes
12 files changed (+92 additions, -7 deletions)
View changed files
📝
pkl-core/src/main/java/org/pkl/core/ast/type/ResolveQualifiedDeclaredTypeNode.java(+2 -1)📝
pkl-core/src/main/java/org/pkl/core/ast/type/TypeNode.java(+11 -4)📝
pkl-core/src/main/java/org/pkl/core/ast/type/UnresolvedTypeNode.java(+20 -2)📝
pkl-core/src/main/java/org/pkl/core/runtime/VmTyped.java(+10 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule2.pkl(+3 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input/types/helpers/someModule3.pkl(+3 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint3.pkl(+25 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/input/types/typeAliasConstraint4.pkl(+5 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule2.pcf(+1 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/output/types/helpers/someModule3.pcf(+1 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint3.pcf(+9 -0)➕
pkl-core/src/test/files/LanguageSnippetTests/output/types/typeAliasConstraint4.pcf(+2 -0)📄 Description
This is one proposal to fix https://github.com/apple/pkl/issues/446.
This changes the behavior of typealiases such that:
This implies that the meaning of a typealias can change depending on where it is resolved from. Given the following:
These two properties have different type checks:
Despite this, they are considered the same typealias.
This is somewhat quirky. An alternative solution to this problem is to require any references from a constraint to be
const. This is just like how classes work. However, this solution would limit the usefulness of typealiases.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.