using private static Main...

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Tony Johansson - 24 Feb 2008 13:48 GMT

Hello!

I'm used to having the access modifier set to public on Main but it works
with private too.

So because of the above must CLR be considered as being a class member.

I think it would be more correct to give compile error if Main have access
modifier set to private. Do you agree?

//Tony

Reply to this Message

Jon Skeet [C# MVP] - 24 Feb 2008 14:42 GMT

> I'm used to having the access modifier set to public on Main but it works
> with private too.
>
> So because of the above must CLR be considered as being a class member.

I don't understand the previous sentence - could you reword it?

> I think it would be more correct to give compile error if Main have access
> modifier set to private. Do you agree?

No, I don't. It's useful being able to make it private - it prevents it
from being called (directly, other than by reflection) from other
managed code.

The CLR is a special case - it's not calling Main in the normal way
from other managed code, it's calling it as the entry point to the
application. I think it's fine for it to be able to see and call a
private Main method.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Reply to this Message

Arne Vajhøj - 24 Feb 2008 15:19 GMT

>> I'm used to having the access modifier set to public on Main but it works
>> with private too.
>>
>> So because of the above must CLR be considered as being a class member.
>
> I don't understand the previous sentence - could you reword it?

Only class members can access private members.

So CLR being able to access private Main gives it the sames
privs as class members.

That is from a interface point of view - from a practical point
of view, then the CLR must have lots of other privs as well
compared to code running inside it.

>> I think it would be more correct to give compile error if Main have access
>> modifier set to private. Do you agree?
>
> No, I don't. It's useful being able to make it private - it prevents it
> from being called (directly, other than by reflection) from other
> managed code.

In the few cases where that would be an issue, then I don't think
reflection being a requirement would mean much of a difference.

Arne

Reply to this Message

Jon Skeet [C# MVP] - 24 Feb 2008 16:47 GMT

> > I don't understand the previous sentence - could you reword it?
>
[quoted text clipped - 6 lines]
> of view, then the CLR must have lots of other privs as well
> compared to code running inside it.

Exactly.

> >> I think it would be more correct to give compile error if Main have access
> >> modifier set to private. Do you agree?
[quoted text clipped - 5 lines]
> In the few cases where that would be an issue, then I don't think
> reflection being a requirement would mean much of a difference.

I just think it's tidier to not expose to the outside world methods
which are designed to be entry points. Typically entry points do things
(such as settings theming etc) which are inappropriate to do from
elsewhere in a program.

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Reply to this Message

Arne Vajhøj - 24 Feb 2008 17:09 GMT

>> In the few cases where that would be an issue, then I don't think
>> reflection being a requirement would mean much of a difference.
[quoted text clipped - 3 lines]
> (such as settings theming etc) which are inappropriate to do from
> elsewhere in a program.

AFAIK then you can not even set a ref to an exe in VS.

If it is a NAnt build, then I would assume the developer
has a decent understanding of what he/she is doing.

But since VS wizards generate private Main then it seems
as if MS agres with you (they don't generate explicit
private keyword though, which I absolutely not like but ...).

Arne

Reply to this Message

Jon Skeet [C# MVP] - 24 Feb 2008 17:23 GMT

> > I just think it's tidier to not expose to the outside world methods
> > which are designed to be entry points. Typically entry points do things
> > (such as settings theming etc) which are inappropriate to do from
> > elsewhere in a program.
>
> AFAIK then you can not even set a ref to an exe in VS.

Yes you can. You couldn't in VS2003.

But even within the exe, you probably don't want to accidentally do it.
Better to not expose it in the first place.

> If it is a NAnt build, then I would assume the developer
> has a decent understanding of what he/she is doing.
>
> But since VS wizards generate private Main then it seems
> as if MS agres with you (they don't generate explicit
> private keyword though, which I absolutely not like but ...).

I tend to not specify private explicitly myself, but that's a whole
different debate...

Signature

Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Reply to this Message

Arne Vajhøj - 24 Feb 2008 15:13 GMT

> I'm used to having the access modifier set to public on Main but it works
> with private too.
[quoted text clipped - 3 lines]
> I think it would be more correct to give compile error if Main have access
> modifier set to private. Do you agree?

CLR calling Main is a special case.

I agree from a puristic point of view and always make my
own Main public.

But whoever designed this at MS did not agree and it will
never be changed (because it would break old code).

You can make it part of your coding convention to always
make it public.

Arne

Reply to this Message

Richard Blewett - 25 Feb 2008 11:21 GMT

>> I'm used to having the access modifier set to public on Main but it works
>> with private too.
[quoted text clipped - 11 lines]
> But whoever designed this at MS did not agree and it will
> never be changed (because it would break old code).

I think I'm missing something. How would it break old code? We're talking
about the wizard generated code here that gets generated once when you
create the project. They would not be changing the meaning of private.
Although I still think it should be private as its a special method for the
CLR to execute not a general purpose method for other types to execute.

> You can make it part of your coding convention to always
> make it public.

Or you could add your own project type or modify the template code they use
to create the project

Regards

Richard Blewett
DevelopMentor
http://www.dotnetconsult.co.uk/weblog2

Reply to this Message

Arne Vajhøj - 25 Feb 2008 23:00 GMT

> "Arne Vajhøj" <arne@vajhoej.dk> wrote in message
>> But whoever designed this at MS did not agree and it will
[quoted text clipped - 4 lines]
> when you create the project. They would not be changing the meaning of
> private.

If the next CLR would not run private Main's, then a few
hundred thousand or millions of programs would not work
any more.

Arne

Reply to this Message

using private static Main...

Free Magazines