Project useCapabilities

[gavr123456789]

https://en.wikipedia.org/wiki/Object-capability_model

1. niva doesnt contain any IO in STD except echo(which is acceptable)
2. Project useCapabilities - special flag in main that will enable capabilities
3. when enabled, you forced to create all the bindings only inside entyPoint of the program
4. libs need to define some main root object that will provides the whole lib API and gets all capabilities

Pattern

1. create some kind of main type for ur program, for example Program readFile: [String -> String]
2. put all the capabilities u need from the main

type Program
  io: IO
  
type IO
  readFile: [String -> String]
  walkDir: [String -> List::String]

Program run = [
  .parseNiva
]

Program parseNiva = [
  // we using external lib that needs to read something from disk
  // it doesnt have other choice than take readFile as a parameter
  // so now we see that it for example cant write to the disk
  externalParserLib = NivaParser readFile: [path -> io readFile path: path, orPANIC]
  
  // also we see that it do not care about read errors, from its signature [String -> String]
  // so we will process errors from the call site

]

io = IO readFile: [
  // use some java bindings here
  File read: (Path name: it)
] walkDir: [...]


p = Program io: io

pros and cons

pros

1. you always see what external lib can do
2. that does not affect scripting since its usually one single file
3. easy way to provide api for different backends, like for js and for kt

cons

1. kinda boilerplate? now u cant just read file from any point of ur program
2. heavy refactoring if u need to do a new capability, like now u need to delete file, so add a new param in ur main type, provide that param from the main file

[gavr123456789]

So basically u kinda constructing ur own io std for each of ur projects.