Dont allow modules to be extended/amended #101

New Issue

adam · 2025-12-30T01:20:48+01:00

adam commented

2025-12-30 01:20:48 +01:00

Originally created by @storm-of-fists on GitHub (Mar 4, 2024).

Something I found confusing when first getting spun up here was this ability to amend/extend a module in addition to doing the same with classes, but with different operators. It feels like the same niche being covered in two ways, which feels like added complexity.

I think either way could work on its own, but the more flexible would be to NOT allow amending/extending modules. Restrict the "rendering" to classes only.

I think this simplifies the mental model and would provide the more consistent codebase. Someone new coming into a project would only ever need to understand that classes act like templates. Not that a module could as well, in addition to learning the top level directives and needing to know what those mean.

I genuinely think pkl is THE thing. I love its design a lot, and would love to see it get easier to use. AND, I think it's just early enough in the project lifecycle to allow this to happen with minimal disruption downstream. I understand that a module should still be an object for inspection purposes, but I think it adds confusion that they too can be amended/extended. For consistency's sake, just rip it out and let classes fill the ecological niche.

Originally created by @storm-of-fists on GitHub (Mar 4, 2024). Something I found confusing when first getting spun up here was this ability to amend/extend a module in addition to doing the same with classes, but with different operators. It feels like the same niche being covered in two ways, which feels like added complexity. I think either way could work on its own, but the more flexible would be to NOT allow amending/extending modules. Restrict the "rendering" to classes only. I think this simplifies the mental model and would provide the more consistent codebase. Someone new coming into a project would only ever need to understand that classes act like templates. Not that a module could as well, in addition to learning the top level directives and needing to know what those mean. I genuinely think pkl is THE thing. I love its design a lot, and would love to see it get easier to use. AND, I think it's just early enough in the project lifecycle to allow this to happen with minimal disruption downstream. I understand that a module should still be an object for inspection purposes, but I think it adds confusion that they too can be amended/extended. For consistency's sake, just rip it out and let classes fill the ecological niche.

adam closed this issue

2025-12-30 01:20:48 +01:00

adam commented

2025-12-30 01:20:48 +01:00

@storm-of-fists commented on GitHub (Mar 4, 2024):

ah shoot, maybe this should have been in the discussions area. well, talk about overlapping niches. Id probably prefer to document this here anyway.

@storm-of-fists commented on GitHub (Mar 4, 2024): ah shoot, maybe this should have been in the discussions area. well, talk about overlapping niches. Id probably prefer to document this here anyway.

adam commented

2025-12-30 01:20:49 +01:00

@storm-of-fists commented on GitHub (Mar 4, 2024):

Down a similar vein of simplifying interfaces, maybe even consider getting rid of the "extends" functionality and only allow spreading of classes into others. No inheritance whatsoever. Then type declarations on class properties are satisfied if the class just satisfies the interface. Like Rust traits.

@storm-of-fists commented on GitHub (Mar 4, 2024): Down a similar vein of simplifying interfaces, maybe even consider getting rid of the "extends" functionality and only allow spreading of classes into others. No inheritance whatsoever. Then type declarations on class properties are satisfied if the class just satisfies the interface. Like Rust traits.

adam commented

2025-12-30 01:20:49 +01:00

@bioball commented on GitHub (Mar 5, 2024):

Modules are special in that they are both classes and regular objects.

You can use a module as if it were another regular class. For example:

Person.pkl

module Person

name: String

import "Person.pkl"

person: Person = new { name = "Sally" }

amends behaves like object instantiation syntax. So, new { name = "Sally" } can alternatively be written like so:

sally.pkl

amends "Person.pkl"

name = "Sally"

And used like so:

import "Person.pkl"
import "sally.pkl"

person: Person = sally

This is a powerful concept that gives you the flexibility to structure your code into multiple files. And, this is something that actually works really well; it's a design that we're quite happy with!

@bioball commented on GitHub (Mar 5, 2024): Modules are special in that they are both classes and regular objects. You can use a module as if it were another regular class. For example: Person.pkl ```groovy module Person name: String ``` ```groovy import "Person.pkl" person: Person = new { name = "Sally" } ``` `amends` behaves like object instantiation syntax. So, `new { name = "Sally" }` can alternatively be written like so: sally.pkl ```groovy amends "Person.pkl" name = "Sally" ``` And used like so: ```groovy import "Person.pkl" import "sally.pkl" person: Person = sally ``` This is a powerful concept that gives you the flexibility to structure your code into multiple files. And, this is something that actually works really well; it's a design that we're quite happy with!

adam commented

2025-12-30 01:20:49 +01:00

@storm-of-fists commented on GitHub (Mar 5, 2024):

hm, well if yall are happy with it, then not much I can do. I just figured it's not as much powerful as it is confusing. Im not sure I understand what it buys you to be able to access the functionality that classes provide via both

define a class in a module and then access that class like "module.Class" or
define a class via the file naming convention and then accessing it directly like import "ClassModule.pkl"

What I tried to get across in my post was that this ability to do both with essentially the same end result is more confusing than it is helpful for structuring code. I could just as easily put my code into different files and then access them like module.Class. Instead I have two ways to do the same thing. IMO that's a nono when it comes to consistency/readability across a codebase.

@storm-of-fists commented on GitHub (Mar 5, 2024): hm, well if yall are happy with it, then not much I can do. I just figured it's not as much powerful as it is confusing. Im not sure I understand what it buys you to be able to access the functionality that classes provide via both 1. define a class in a module and then access that class like "module.Class" or 2. define a class via the file naming convention and then accessing it directly like import "ClassModule.pkl" What I tried to get across in my post was that this ability to do both with essentially the same end result is more confusing than it is helpful for structuring code. I could just as easily put my code into different files and then access them like module.Class. Instead I have two ways to do the same thing. IMO that's a nono when it comes to consistency/readability across a codebase.

adam commented

2025-12-30 01:20:50 +01:00

@storm-of-fists commented on GitHub (Mar 5, 2024):

I promise Im not trying to be rude btw, I appreciate the feedback a lot. If it's more helpful, I'm willing to jump on a discord call or something, its usually easier to explain this sort of thing in words.

@storm-of-fists commented on GitHub (Mar 5, 2024): I promise Im not trying to be rude btw, I appreciate the feedback a lot. If it's more helpful, I'm willing to jump on a discord call or something, its usually easier to explain this sort of thing in words.

adam commented

2025-12-30 01:20:50 +01:00

@storm-of-fists commented on GitHub (Mar 11, 2024):

Ok, thinking about this some more, the file extension/amend method is actually nice for allowing less technical professionals an interface for them to interact with the codebase. It isn't as 'coding' as it is filling a text file. A form at an office.

Alright, I understand why to do this now. Closing.

@storm-of-fists commented on GitHub (Mar 11, 2024): Ok, thinking about this some more, the file extension/amend method is actually nice for allowing less technical professionals an interface for them to interact with the codebase. It isn't as 'coding' as it is filling a text file. A form at an office. Alright, I understand why to do this now. Closing.

adam referenced this issue

2025-12-30 01:24:22 +01:00

[PR #101] [MERGED] Prepare 0.25.2 release #416

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pkl#101