Program startup/shutdown

[jclark]

Not yet clear if we have the right semantics here yet.

In particular, the fact that services in all imported modules are started seems strange, and not very consistent with how main is handled. What does it mean for a module import to be unused if the way to use a service is to import it?

There have also been requests from Cellery team to restore multiple entry point capability.

[jclark]

We could, like Go, do import ... as _ to mean that it is not used directly.

https://medium.com/golangspec/import-declarations-in-go-8de0fd3ae8ff

[jclark]

What about scheduled tasks (appointments)? They need to keep program alive. Tasks are scheduled via ballerina/task library functions.

[jclark]

We should also consider how forever should work. Can we make it more like a listener?

[jclark]

We should also think about #101 at the same time.

[jclark]

The following aspects of the current design make me feel uneasy

1. function entry point does not have its own syntax, whereas service entry point uses special syntax
2. function entry point uses main , whereas elsewhere in Ballerina names that have special semantics for Ballerina are prefixed with __ (e.g. __init method)
3. The approach to main means there is no good solution to how to do module initialization Explicit initialization function for modules  #101
   • __init function is wrong because it is unlike main
   • init function is wrong because it is unlike __init
   • special syntax is wrong because it is unlike main
4. You can have only one function entry point in a module, but you can have multiple service entry points
5. Multiple function entry points are natural when you want a command with an interface like git, where the first argument indicates the subcommand
6. functions called main is only called in the root module, whereas service entry points are called in all modules
7. always calling service entry points in a module other than the root module, without some explicit indication that this is what the user wants, seems weird and confusing (Starting a service in imported module #215 is making this point)

[jclark]

My current preference would be:

• The command line interface is constructed from all public functions in the root module, and there are built-in annotations that allow this to be customized. There are a couple of ways the CLI could deal with multiple public functions:
  • the first argument in the CLI would be the name of the function to invoke (git-style)
  • the name of the function is specified as an option, which the function defaulting to main if it exists
• Only services in the root module are started automatically.
• We use an __init function for Explicit initialization function for modules  #101

[sanjiva]

How is the root module identified?

[sameerajayasoma]

Following describes the proposed behavior in the upcoming packerina specification.

• Ballerina project is a directory in which you can manage a set of Ballerina modules.
• The entry/root module is a module which has a main function and/or one or more services.
• ballerina build foo command creates an executable program if foo is a root module.
• ballerina build command create executable programs for all root modules in a project.

IMO, root module is a module that has a main function and/or one or more services.

[sanjiva]

We discussed removing the latter (build without an arg generating multiple binaries) in the last call right? Or did we conclude we want to keep it? I think its very confusing for users.

I'm ok with James has proposed (and this is what we had which we removed ...) but we need to make sure the UX is acceptable simple cases: when the user only has a single public entrypoint (possibly called main even) then it should not require to name the entrypoint.

[jclark]

I believe we decided not to do the generating multiple binaries thing. I agree it is confusing. It could be an option, but it shouldn’t be the default behaviour with no args.

[hevayo]

Some projects might have more than one module with an entry point. A common use-case would be a micro-services project with multiple services divided in to modules. And a user will want to build executable for each service with a single build.

One solution is to capture which modules to build in Ballerina.toml and build those when you execute build command.

[sanjiva]

Yes that's possible .. but given we don't allow circular imports, each root module is the start of a tree. I'm ok with having a TOML option to set a list of root modules as long as the default works without any setting. Plus we can do this after the initial release.

…

On Wed, Jun 19, 2019, 7:25 AM Joseph Fonseka ***@***.***> wrote: Some projects might have more than one module with an entry point. A common use-case would be a micro-services project with multiple services divided in to modules. And a user will want to build executable for each service with a single build. One solution is to capture which modules to build in Ballerina.toml and build those when you execute build command. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#44?email_source=notifications&email_token=AAR7FPHPXHG47AYPBUSDFXLP3GYL7A5CNFSM4HBNM3XKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYAUSSI#issuecomment-503400777>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAR7FPFQ6YDD2WKS5G6WYDDP3GYL7ANCNFSM4HBNM3XA> .

[jclark]

In today's call, I suggested layering things a little differently from how we currently do.

In the language layer, things are roughly as they are now in the spec but without the "main" phase:

• we have a root module
• add the ability of a module to specify a __init function Explicit initialization function for modules  #101
• program startup/shutdown semantics are:
  • initialize each module, with each module getting initialized after all the modules that it depends on; this includes running __init, which can do everything; if module initialization fails, the program exits;
  • after initialization, if there are no listeners registered, exit with success
  • otherwise , start the listeners
  • __init in the root module can do the job of main
• probably need to add the ability to import a module just so its __init gets called (e.g. import ... as _)

In the platform layer:

• there is a function to get the program's command line arguments, exactly as supplied, as an immutable array (similar to functions to get environment variables)
• configuration feature (Add concept of configurability to language #41) will be able to use command line as source of configuration data
• there is a way to generate a command-line interface from a module; one way would be as follows
  • all public functions of the module contribute to the CLI
  • if there is more than one, then first command-line argument says which function to call
  • if there is only one, by convention call it main
  • effect is to generate a new module with an __init that gets the program's command line arguments, parses them and calls the public functions
  • this new generated module, which imports the old root module, becomes the new root module