Emulate Native Types like Lists and Dictionaries via Proxy Objects

[skorfmann]

🚀 Feature Request

Affected Languages

• TypeScript or Javascript
• Python
• Java
• .NET (C#, F#, ...)

General Information

• JSII Version:
• Platform:

• I may be able to implement this feature request

• This feature might incur a breaking change

Description

For cdktf there's the use case of having to support complex computed types. These are lists and dictonaries, which reference attributes not supplied by a user.cdktf has to provide a way to reference these attributes, with the following goals in mind:

• Fully typed
• Idiomatic usage
• jsii compatible

Example:

The acm cert validation resource has a domainValidationOptions attribute, which is a list of AcmCertificateDomainValidationOptions:

export interface AcmCertificateDomainValidationOptions {
  readonly domainName?: string;
  readonly resourceRecordName?: string;
  readonly resourceRecordType?: string;
  readonly resourceRecordValue?: string;
}

What I'm looking for, is a way to provide a way to access these attributes which feels natural to the user of the given language. In Typescript this would be something like certValidation.domainValidationOptions[0].resourceRecordName.

In Typescript, this could be achieved with a proxy object. However, there's no way to represent this in jsii at the moment.

The current implementation in cdktf makes the above example accessible like this: certValidation.domainValidationOptions('0').resourceRecordName (the string type will likely be replaced by number) and returns a reference like this acm_certificate.domain_validation_options.0.resourceRecord. That's close to our ideal requirements, but lacks the idiomatic aspect.

Proposed Solution

Not sure how this could be achieved in a way which supports all target languages. In particular, since only Python seems to have a similar way of using proxy objects to emulate native types like lists and dictionaries.

[RomainMuller]

We had thought about it in the past and that is definitely something we'd be considering to do. The main challenge here (and the reason we had deferred this work so far) is that providing a full implementation of the List or Map contracts can be a rather large endeavor (just look at the abstract methods one needs to implement in the Javadoc for AbstractList!).

At the end of the day, this is a simple matter of programming. We only need to find the time to do this!

It might be interesting to get an RFC going to get a plan figured out. Let me know if you're interested in getting something started 🙃

[skorfmann]

Cool, thanks for providing a bit of context.

It might be interesting to get an RFC going to get a plan figured out. Let me know if you're interested in getting something started 🙃

Yes, I'll get that started.

[github-actions]

This issue has not received any attention in 2 years. If you want to keep this issue open, please leave a comment below and auto-close will be canceled.