Dont allow modules to be extended/amended

[storm-of-fists]

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.

[storm-of-fists]

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]

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.

[bioball]

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!

[storm-of-fists]

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.

[storm-of-fists]

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]

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.