How to prevent root of a module from being used as a type?

[ric2b]

Hey, still trying to learn Pkl and ran into a question :)

Is there a way to prevent the root of a module file from being used as a type, if the file is defining a few classes but the root has no meaning besides being a package of classes?

For example, if I have this Vehicle.pkl:

abstract class Vehicle {
  manufacturer: String
}

class Car extends Vehicle {
  transmission: "automatic" | "manual"
}

class Boat extends Vehicle {
  has_sails: Boolean
}

I want the following to be possible:

import "Vehicle.pkl"

vehicles: Collection<Vehicle.Vehicle>
cars: Collection<Vehicle.Car>

But not this:

import "Vehicle.pkl"

vehicles: Collection<Vehicle> // Has no meaning
cars: Collection<Vehicle.Car>

I'm also a bit confused about what the "module" property is intended for, if I add module company.MyModule to the top of Vehicle.pkl I can still refer to the the type Vehicle directly in other files.

And is there a way to remove the boilerplate of referencing the abstract class with Vehicle.Vehicle and instead have the base class be the root export of the Vehicle.pkl file?

(I'm probably getting a bunch of Pkl concepts mixed up, sorry about that)

[bioball]

Hi; a module special because it is both an object, and a class. The module is intended to be usable as a type. I would structure your code this way:

abstract module Vehicle

import "Vehicle.pkl" // self-import

manufacturer: String

class Car extends Vehicle { // extends the module's class
  transmission: "automatic" | "manual"
}

class Boat extends Vehicle {
  has_sails: Boolean
}

[ric2b]

Oh, neat, that works, thanks :)

It's not very intuitive, though, maybe a documentation note about this would be useful for others (unless this use case is considered weird)

[bioball]

It's actually a very normal use-case! We follow this pattern in our own code, for example here: https://github.com/apple/pkl-pantry/blob/main/packages/pkl.experimental.syntax/ExpressionNode.pkl

You're right that this isn't covered in our docs. We're still finding our footing around where to put advice and tips. For instance, this doesn't belong in the language reference, nor the tutorial. But, that will mature over time. Maybe would be a good blog post.