[Enhancement] Proposal for new language feature for the short hand property #1275
Description
Feature Request
Is your feature request related to a problem? Please describe:
When I'm working I like convenience and flexibility, and that's why I love KCL! I have an idea that I think will push that frontier a bit further.
Describe the feature you'd like:
Javascript is a pretty horrible language, but there is one cool feature that came out in ES6 - object property shorthand!
In short, when creating objects, we can use shorthand notation to assign variables as object properties with the same name.
// normal assignment
function createMessage (message, id) {
return {
message: message,
id: id,
timestamp: Date.now()
}
}
// shorthand
function createMessage (message, id) {
return {
message,
id,
timestamp: Date.now()
}
}In KCL, there could be shorthand assignment too, not only by variable name, but by type as well! Examples:
# let's define some basic schemas
schema CPUOptions:
cores: int
threads: int
schema DiskOptions:
size: int
$type: "sdd" | "hdd"
schema VirtualMachine:
name: str
cpu: CPUOptions
disk: DiskOptions
# normal assignment
vm = VirtualMachine {
name = "vm"
cpu = CPUOptions { cores = 1, threads = 1}
disk = DiskOptions { size = 32, $type = "ssd"}
}
# now lets add some matching names
name = "next_vm"
cores = 2
threads = 4
disk = DiskOptions { size = 8, $type = "hdd"}
# shorthand assignment by name
vm2 = VirtualMachine {
name
cpu = CPUOptions { cores, threads } # cores and threads also shorthand assigned by name
disk
}
# shorthand assignment by type
vm3 = VirtualMachine {
"last_vm"
# cpu_options identifier is not necessary because VirtualMachine expects CPUOptions
CPUOptions { cores = 4, threads = 8} # cores/threads cannot be shorthanded by type because they are both the same type and it's ambiguous
# one DiskOptions is expected by VirtualMachine
DiskOptions { 32, "ssd"} # + int and str can also omit identified
}Describe alternatives you've considered:
N/A, I just thought this feature was really cool
Teachability, Documentation, Adoption, Migration Strategy:
As a bonus if that would work outside schemas and instances, that would be so convenient. Currently, I'm working on IaC tool and if I define e.g. one provider (like terraform provider) in a file, why should I add identifier to unique resource (I know it probably have very logical reason, but like I said, I like flexibility 😃)? But, when I need to add second instance, another shorthand instance cannot be added and I must use identifier.
Example:
Kubernetes {
host = example.tdd
context = rancher-asd
}
my_other_cluster = Kubernetes {
host = localhost
context = minikube
}That's all from me, let me know what you think!