Implement nested types #177

New Issue

2025-12-30T01:21:46+01:00

adam commented

2025-12-30 01:21:46 +01:00

Originally created by @HT154 on GitHub (Jun 30, 2024).

I'd like to be able to do something like this:

class MyA {
  properties: Properties

  class Properties {
    prop1: String
  }
}

class MyB {
  properties: Properties

  class Properties {
    prop2: String
  }
}

aProps: MyA.Properties

Currently, this requires disambiguating classes with only naming, which can lead to very long class names with more deeply nested structures. This code today must look like this:

class MyA {
  properties: MyAProperties
}

class MyAProperties {
  prop1: String
}

class MyB {
  properties: MyBProperties
}

class MyBProperties {
  prop2: String
}

aProps: MyAProperties

Originally created by @HT154 on GitHub (Jun 30, 2024). I'd like to be able to do something like this: ```pkl class MyA { properties: Properties class Properties { prop1: String } } class MyB { properties: Properties class Properties { prop2: String } } aProps: MyA.Properties ``` Currently, this requires disambiguating classes with only naming, which can lead to very long class names with more deeply nested structures. This code today must look like this: ```pkl class MyA { properties: MyAProperties } class MyAProperties { prop1: String } class MyB { properties: MyBProperties } class MyBProperties { prop2: String } aProps: MyAProperties ```

adam commented

2025-12-30 01:21:47 +01:00

@bioball commented on GitHub (Jul 2, 2024):

I'm kind of bearish on this idea--this feature is a request to use classes as namespaces, and I don't know if that is a suitable use of classes.

Today, I'd suggest doing what you're doing (disambiguate the plain class name), or, alternatively, put them in different modules.

@bioball commented on GitHub (Jul 2, 2024): I'm kind of bearish on this idea--this feature is a request to use classes as namespaces, and I don't know if that is a suitable use of classes. Today, I'd suggest doing what you're doing (disambiguate the plain class name), or, alternatively, put them in different modules.

adam commented

2025-12-30 01:21:47 +01:00

@HT154 commented on GitHub (Oct 19, 2024):

My motivation for opening this is actually described exactly in https://github.com/apple/pkl-pantry/issues/40

This is definitely something I'd discourage in normal use of Pkl, but when used as a tool for disambiguating identically named types without manual name mangling—particularly in conjunction with Pkl code generation—I think this stands to be really valuable.

Also, I think could play a role in a potential non-trivial user generics implementation that may need to consider associated types (like Swift), which would motivate allowing typealias in these same contexts.

@HT154 commented on GitHub (Oct 19, 2024): My motivation for opening this is actually described exactly in https://github.com/apple/pkl-pantry/issues/40 This is definitely something I'd discourage in normal use of Pkl, but when used as a tool for disambiguating identically named types without manual name mangling—particularly in conjunction with Pkl code generation—I think this stands to be really valuable. Also, I think could play a role in a potential non-trivial user generics implementation that may need to consider associated types (like Swift), which would motivate allowing `typealias` in these same contexts.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#177