Does the run() function need to be shared?

[lucaswerkmeister]

Try the following code

void run() {
    print("Hello, World!");
}

It compiles fine for both the Java and Javascript backends. However, when running it in Javascript, you get the following error

The specified method "run" does not exist or is not shared in the com.example.helloworld/1.0.0 module

while it runs perfectly fine in Java.

I don’t care what behavior is the correct one here, but the inconsistency is pretty confusing when you’re e. g. trying to test that your changes in both backends produce the same result :) (especially if you just skim through the message and only read the “does not exist” part)

[gavinking]

Yeah yeah, I know. I've been trying to convince @chochos that the shared shouldn't be necessary.

[chochos]

Fiiiiiine I'll get on it. Just please open an issue in ceylon-js

[lucaswerkmeister]

I don’t know, the JS behavior makes more sense to me. I know @gavinking is probably concerned about cluttering even the smallest sample code with “unnecessary” shared annotations (see #56), but IMO, people have accepted public static void main(String[] args), they’ll accept shared void run() as well.

[lucaswerkmeister]

Guys, it’s ridiculous how long this “high priority” and really simple issue has remained open, just because I refused to open an issue in ceylon-js…

I’ll repeat my vote for the JS behavior, because:

• adding shared isn’t too much of a hassle, and
• it’s scary that anyone can run any toplevel function of my module just because it happens to have no undefaulted¹ parameters (initDBConnection()? uninstallConfig()? format(String drive = "C:")?).

Discussion?

^{1) Yes, ceylon run and the IDE will happily run a function with parameters as long as they’re all defaulted.}

[FroMage]

One one hand, Java requires the main methods to be shared. On the other, it's handy to have several main methods that help testing that are not visible to API users. I don't really care either way, but I think it's more useful to allow running unshared toplevels.

[DiegoCoronel]

personally I prefer it to be shared , and while doing some demonstrations of ceylon always been asked to run on JS I had to leave everything to modifying to use shared ... anyway, shared or unshared we need to be consistent in both platforms .. the behavior that we have today is frustrating to explain this lack of consistency

[gavinking]

Well the thing is, suppose I have a method void foo() { ... } that I'm working on in a source file in the IDE. Are you really going to force me to add a shared annotation to it just to be able to run it for testing purposed? That seems so ... heavy-handed ... to me.

[lucaswerkmeister]

Perhaps we could add an exception for “local modules” (from repo modules/ / compiled from source/ / …)? I’m just not comfortable with ceylon run --run=any.module.package::anyFunction any.module…

[DiegoCoronel]

Well, my strongest argument here is that if you have a private method then it is often dependent of the environment context or the own instance state, this way its usefull just in rare cases, normally when you want to run the method its probably because its also shared.

[tombentley]

We could give the IDE the ability to run non-shared functions. It is an IDE after all, and can do all sorts of

[tombentley]

...Special things

Stupid phone

[gavinking]

Well then this would become only an issue for the ceylon run tool, with no impact anywhere else.

[quintesse]

Well that doesn't seem right, if the IDE can do it why can't we on the command line? So then we would be back at square one. I don't care too much one way or the other, both backends should just behave the same, period.

The problem with the JS backend is, IIRC, that it cannot execute private methods. So the JS compiler would have to make all parameterless toplevel funtions public to make things work. That might be an acceptable tradeoff though.

[lucaswerkmeister]

Well that doesn't seem right, if the IDE can do it why can't we on the command line?

Because the IDE wouldn’t run arbitrary modules?

[quintesse]

If the IDE works like that I don't see why the command line can't do the same. I definitely don't like the idea that you'd be able to do more in the IDE than on the command line. "Oh I need to test this private function, better fire up the IDE". Let's not go there.

[ncorai]

Even a simple rule stating the mere existence of moduleX.packageY implies access to all private members from moduleX.packageY.test would in my opinion be an improvement to the current state of things. Alternatively, you could have a production environment where access rules are enforced and a test environment where they aren't.

[gavinking]

Resolved affirmatively.

[lucaswerkmeister]

The ceylon run tool still allows you to run unshared functions.

[lucaswerkmeister]

The ceylon run tool still allows you to run unshared functions.

Is that a ceylon-runtime issue because the CeylonRunTool allows it, or a ceylon-compiler issue because a main() is generated? (Or both?)

[quintesse]

Well I think at least having it confirmed is something. Both tools have already worked different from the beginning, letting this slip to 1.1.5 won't be a disaster. I opened an issue for it on ceylon-runtime.