stz getters and setters

stz getters and setters
Photo by Jon Tyson / Unsplash

Just as an side back to the getters and setters of Person's name. My intention is that declaring the class auto-creates the getter and setter for you.

Person = ( name: string, age: (quantity of: seconds) )

However, how do you specify which variables you want to be public and which variables you want to be private? The dumbest solution is to once again prefix the thing with something, such as _, to indicate it is private... but that's not enough. Do you mean it to be private to the file or private to the package?

In other code where I've got parameters I've been using a longer form to declare a class. Technically a structure declaration is enough to be a class but somethings you do need more:

list = { class |
  parameters: (of: object-t,),
  constants:  (element-class: of,),
  traits:     (sequenceable-t of: element-class,),
  variables:  (
    elements: &array of: element-class,
    length: uint,
    allocator: &memory-allocator,) }

I want everything there except length to be private and I want length to be read-only for the public but writable for the package.

It's not as simple as having different buckets for variables. Instead my idea of auto-generating the getter/setter is simply wrong. I wanted to save typing and instead I've made a small mess.

The solution is two fold. The first is to have a syntax for accessing structured data that isn't a method dispatch. This is easy to do. We aren't using . right now so let's use it.

foo = ( name: string, age: (quantity of: seconds) )
foo.name: 'Bob'
bob-string = foo.name
[ a-foo name: a-name | &!foo, string | a-foo.name = a-name ]

We now have our private access to the data in a class and the ability to make it public. Next we also add getters/setters as a convenience api when declaring a class. This might take some fiddling to get the API right. There's also the problem that the structure needs access to parameters to make sense.

The current class definitions are a bit hand-wavey right now. Calling parameters: effectively introduces a scoped binding for each parameter that is resolved later when the type is fully realised. I'm not happy with some of this. More work required.

Unlike most of the other blog posts, this one doesn't have an immediate answer. Watch this space.