Final Keyword

[AgentK9]

Hey!

Very new to pkl, of course, but messing around and it seems like there's room for a final keyword. I could just be missing something in the docs, but there is a use case for classes and abstract classes that cannot be significantly changed when extended.

For example, see below:

// Valid
abstract final class FinalAbstractExample {
    abc: Int?
}

// Throws Error - abstract class cannot extend abstract final class
abstract class ChildFinalAbstractExample extends FinalAbstractExample {}

// Throws Error - class cannot add fields to abstract final class
class ChildFinalExampleA extends FinalAbstractExample {
    def: Any
}

// Throws Error - class cannot make an inherited final field's typescope larger
class ChildFinalExampleB extends FinalAbstractExample {
    abc: Number?
}

// Valid
class ChildFinalExampleC extends FinalAbstractExample {
    abc: Null
}

// Valid
final class FinalExample {
    xyz: String?
}

// Throws Error - class cannot inherit from final class
class ChildFinalExampleD extends FinalExample {}

[bioball]

Thanks for the idea! Can you describe what the goal of this feature is? What are some practical applications that benefit from this keyword?

FYI: Pkl classes are "final" by default, and cannot be extended without the open or abstract modifiers.

You might have noticed that classes today can have their properties overridden to be any other type. This is something we might change in the future, to require that a property is a sub-type of the overridden type. Is that what you mean by final here?

[AgentK9]

Yeah so I think I missed/forgot the part where pkl classes are "final" by default.

There are two cases where I think that "final" could be useful:

1. To limit child fields - see cases 3 and 4 above.

To be more specific, I'm building something like this:

abstract final class BaseObject {
    optionalval: String?
    other_field_a: Int
}
class RequiredString extends BaseObject {
    // no extra fields
}
class InvalidObject extends BaseObject {
    test_field: Int  // raises error
}

BaseObject doesn't want any child classes to add on any extra fields, so it should be declared final. It's more of a communication of design intent than anything.

2. To limit inheritance - see case 2 above.

It's possible that this should be a different keyword (closed?) but I think the idea still stands - what if you want an abstract class to only have non-abstract children? This is linked to the above in that the main use case I can think of for an abstract class to inherit from an abstract class is to add fields.

I hope this makes sense! Thanks for the quick response and the clarification on class inheritance. I do find it somewhat surprising that pkl doesn't enforce subtypes of defined types for inheriting classes, but we'll get there!

[HT154]

I'm a little confused as to the utility of both of these cases. I'm sure this is partly due to these being reduced examples, so sharing more might be helpful.

In case 1, what's the utility of using an abstract class at all? If the fields are all the same, why not have a single concrete class? The only reason I can imagine is related to subclasses having methods that behave differently, but it's difficult to see that motivation from what you've shared. Also, how would you expect this to interact with hidden properties?

The above confusion extends to case 2 as well. Definitely difficult to motivate without a strong motivation for case 1.

Side note: there's definitely some utility to a "clopen" class/module that allows subclasses but only the addition of hidden properties. This would be nice in cases where a target system expects a specific format, but users wish to build some abstraction over that format (eg. derive many/complex properties from a new/simple hidden property. That said, I think these cases are actually better served by the class-as-a-function pattern, eg.

open class MyOutput {
  name: String
  values: Listing<String>
}

// hidden extension
class OrderedOutputSubclass extends MyOutput {
  local _name = this.name
  hidden count: Int
  // ideally, defining a new non-hidden property here could error if the parent is "clopen"
  values {
    for (i in IntSeq(0, count)) {
      "\(_name)-\(i)"
    }
  }
}

ex1 = new OrderedOutputSubclass {
  name = "test"
  count = 3
}

// class-as-a-function
class OrderedOutputCaaF {
  name: String
  count: Int

  fixed result: MyOutput = new {
    name = outer.name
    values {
      for (i in IntSeq(0, count)) {
        "\(name)-\(i)"
      }
    }
  }
}


ex2 = new OrderedOutputCaaF {
  name = "test"
  count = 3
}.result

// ex1 and ex2 render identically
// but for ex2 the base class need not be open

[AgentK9]

In case 1, the fields are not necessarily all the same - the types may be different. The field names are the same.

For case 2 I don't understand your confusion - having an abstract class that can't be extended by another abstract class seems pretty straightforward to me.