Newbie question on overriding values

[spastorclovr]

Hey there 👋

I coming from KCL land, where you have options to merge or replace value using either ":" or "=" when assigning values to variable.

I was wondering how this could be achieve in Pkl?

class App2 {
    name:String
    list {
       2
       3
    }
}

baseApp:App2 = new {

   name = "toto"
}



child = (baseApp)  {
   list  {
      10
   }
} 

for instance, how could I have child having only the value "10" in its property list ?I want to replace and not merge.

Thanks!

[spastorclovr]

I have actually managed to do this by using

child = (baseApp)  {
   list = List(1)
}

Is it the way to go? Feels a bit cumbersome.

[bioball]

Pkl's way to do this is by either amending, or assigning.

class App2 {
    name: String
    list: Listing<Int>
}

baseApp: App2 = new {
   name = "toto"
   list { 1; 2 }
}

child: App2 = (baseApp) {
  list = new { 1; 2; 3 } // overwrite `list`
}

child2: App2 = (baseApp) {
  list { 1; 2; 3 } // amend parent `list`
}

See output here: https://pkl-playground.vercel.app/?share=suppose-friend-food

Also, by the way, new { ... } means "amend the default value" (see the language reference for a detailed explanation). Generally in Pkl, you want to make sure the default value is empty. So, don't do this:

class App2 {
    name: String

    // bad; when defining a class property, don't also provide its data
    list: Listing<Int> = new { 1; 2; 3 }
}

[spastorclovr]

Thanks so much for taking the time to explain and lay out an example. (and sorry for the delay)

Why having a non-empty default value is considered bad practice? This is very useful for us in KCL where we have a base app,
with default values and we override only the specific values per env.

Thx again.

[HT154]

Why having a non-empty default value is considered bad practice? This is very useful for us in KCL where we have a base app,
with default values and we override only the specific values per env.

Whether defaults are included in the schema is a pretty situational decision. There are some cases where it's desirable or necessary (one example is the Class-as-a-function pattern), but often when designing a schema it helps to not provide defaults to avoid this specific point of confusion. This is also a helpful way to separate concerns: often a schema and a set of "base" values do not need to be tightly coupled and keeping them separate makes it easier to reason through. In a few cases where a schema isn't designed for wide consumption or the schema and defaults are very tightly coupled it may make sense to combine them.

It's also worth noting that you can fully overwrite the defaults still, like so:

class App2 {
    name: String
    list: Listing<Int> = new { 1; 2 }
}

baseApp: App2 = new {
   name = "toto"
   list { 3 }
}

child: App2 = (baseApp) {
  list { 4 } // amend parent `list` = { 1; 2; 3; 4 }
}

child2: App2 = (baseApp) {
  list = new { 4 } // amend default `list` = { 1; 2; 4 }
}

child2: App2 = (baseApp) {
  list = new Listing { 4 } // overwrite `list` = { 4 }
}