[FR/Idea/Suggestion] Modules: "public" & "static" functions

[xplshn]

Hi, will modules have a clear way to distinguish public functions and variables, etc, from private ones? Like C?

Tho I think a Go-like style is suitable.

[yassinebenaid]

amm, I just realized that I made a mistake in the design of modules.

Here is how modules work at the moment:

1. you write a module with a bunch of functions.
2. in another project, you require that module using a path and a commit hash.
3. you get access to all functions defined in both modules.
4. the main module always overrides the functions defined in the required modules

This approach is full of problems:

1. the fact that requiring a modules exposes all functions to the global scope is so full of anomalies. because the required modules can override functions of each other.
2. it's not possible for libraries to require other libraries. this limitation is related to the above issue. because if you require a library at a commit A. and another library you're using requires that same library at commit B. these different versions of same library will override each other.

in other words. the design I approached in bunster is not convenient at all. because it doesn't guarantee any encapsulation.

alternative (better) design.

we won't expose the functions of a library. we will expose the library it self as a command. and let the library define the interface to its users. we will drop the term library from our terminology. because libraries will look just like any normal bunster module. in fact; bunster libraries can be any valid bunster module.

let's see how:

1. you write a module just normal just like if it's a standalone program:

main.sh:

 if [ $1 = "hello" ]; then
      hello
 else 
     bye
 fi

other.sh

 function hello(){
     echo "Hello World"
 }

 function bye(){
     echo "Bye bye"
 }

now, this module does not look like a library, because it contains a main.sh file, which means it's a main module. can be compiled to a standalone program.

But, if you put this into a github repository at github.com/foo/bar. people can use it as a library in their own modules like this:

add this to bunster.yml file:

require:
  foobar: 
    from: github.com/foo/bar
    version: 1234567890abcdefgh

now, on their own modules, users can use your module as a program:

foobar hello 

# prints "Hello World"

foobar bye 

# prints "Bye bye"

Notice that the library does not expose any functions. instead, it exposes it self as a program. this means, that library authors will have full control on the API they want to expose, while keeping all their functions private.

This also means, that libraries can still be compiled to standalone programs. which suppots the idea of write-once-use-anywhere. anyone can use any bunster program as a library, there won't be any difference between a main module and a library.

any thoughts @xplshn

by the way, there is already an open issue for this concern: #260

[xplshn]

I think bunster modules should be shell scripts, or shell in bunster dialect.
Import would behave like a remote @embed, exposing the module, the import directive would let a person import X module as Y, so that: Y.Function() is a call to the X module's Function()

In shell, the user could do: "Y Function arg1 arg2 arg3" (where arg1, arg2, arg3 are arguments being passed to the function)

Also, I think directives should be in a comment, so that bunster dialect shell is also valid shell.

[xplshn]

Any progress with this?

[yassinebenaid]

This is work-in-progress. I was trying to figure out a way to work-around some limitations in bunster regarding the trap and exit builtin commands. took me too long.

I'll look back at this issue as soon as I solve that issue as it is way more important.

thanks for patience.