Really the desired effect? (unshared main side effect)

[nevdelap]

Hi Chuck,

I thought the main not having to be declared shared was a convenience, which it would be, except that it changes the behaviour of the program because the main wrapper constructs your class if your main isn't shared, meaning that the behaviour of the shared version and 'for convenience of not typing is shared' not shared version are not the same.

Was that your intention?

I'm thinking that if the convenience has a side effect it doesn't warrant the saving of not typing 'is shared'.

Nev

One version.

Code: Select all

class A

   cue init
      base.init
      print '1'

   def main is shared
      A()

1

What you have to change if you don't have the is shared convenience to have the same behaviour.

Code: Select all

class A

   cue init
      base.init
      print '1'

   def main
      #A()
      pass

1

Broken version that doesn't work as intended when thinking the 'convenience' wouldn't change the behaviour.

Code: Select all

class A

   cue init
      base.init
      print '1'

   def main
      A()

1
1

[Charles]

An instance is constructed because that is the only way an instance method can be invoked. I don't know that it was ever advertised that "def main" was guaranteed to be side effect free. There are other things you can do in Cobra that may have side effects. For example, "assert obj.foo" invokes a method .foo which may have a side effect. Now when you run with "cobra -include-asserts:no" or "cobra -turbo" the side effect is removed. You have to keep such things in mind.

Test sections could also have side effects.

I haven't run into the problem with main because typically my initializers are fairly side effect free and also because I usually keep the main/program small and secluded from much of the rest of the app.

I don't think a change is needed here.

Btw where are there 1s in your post?

[nevdelap]

I wasn't talking about side effects of the things done 'in' the main.

I was talking about by not putting the 'is shared' the side effect is that your class gets constructed without you constructing it which I don't think is an intuitive result of removing 'is shared'.

Just seems to me it makes not having to put 'is shared' on main more of a quirk than a feature.

The 1s are the output of the programs. Showing the double construction of A() in the third one.

Certainly asserts should never be written to have side effects and tests shouldn't have side effects either since they could invalidate the testing, but as you say, that is just something to be aware of.

[nevdelap]

Thinking about it more. Essentially...

class P, def main is shared - is the entry point to the program.

class P, def main - causes P.init to be the entry point to the program and main to be a method that just happens to get called subsequently, where you must be mindful that you needn't construct your P because it was done explicitly for you.

Cobra let's you have a .main method that is not shared/static. But this is a feature of the language[snip]

I just wonder how it's a 'feature' when it alters the semantics of main like this. Am I not seeing some additional benefits? (on top of saving typing 'is shared'?)

[Charles]

An additional benefit is that it gets you to instance methods faster which is where most coding belongs in an OO language. Shared/static methods are definitely overused in .NET applications from my experience. One difficulty with them is that they tend to encourage shared/static fields (e.g., global state) which is harder to manage and can be a source of bugs. Another difficulty with shared/static is that without instances you cannot do interesting things like put objects in a list, or a dictionary, serialize them, mock them, override the methods, etc.

The problem I perceive with C#'s "static void Main" is that newbies tend to keep using "static" until they end up with a program that might as well have been done in C or Pascal with a bunch of global vars and global subroutines.

Also, I have never experienced a side effect from using "def main" without "is shared". Maybe that's because I tend to put the "def main" in a fairly small class or because my .init cues tend to not have side effects that would ever bother me.

Btw C# does not guarantee that Main() is the entry point. If the class with Main() has a static constructor then it's code will be executed before Main() which I presume should bother you in a similar manner.

[nevdelap]

I agree with you on all those points, and I've obviously explained myself poorly, because I'm only talking about the difference between is unshared and shared versions of main. The side effect of simply your object being instantiated when you didn't ask for it to be. Nothing else, no other side effects, nothing any grander than that, nothing to do with the code in the program being written. Though one other slight quirk is that the invariant on the class with the unshared main will/should get called only after construction and at the end of the program because at all other times it is still in the context of that main method. But, I guess it's trivia, and just something to be aware of with Cobra.

Thanks for your replies Chuck.

[hopscc]

I dont really see a problem.
If your initializers dont have side effects and you can bear the implicit invisible construction of your main bearing class instance dont declare main as shared - you'll probably be alright until
either of those two surfaces to nip you unexpectedly

Otherwise if you prefer it explicit Just declare your main as 'is shared' and do your own construction (or whatever).

Its just a convenience for a common(ish) idiom; if its not convenient theres no obligation to use it .

Also this was a latterly added feature - A better ( or in fact some) documentation (wiki) of the two forms and the various tradeoffs/implementation details
might help clarify some.