static member function, with no public/private/etc.

[Zytan]

What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.

thanks

Zytan

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.

Yes - private.

Arne

 

[Zytan]

Yes - private.

Thanks Arne!

Zytan

 

[Jon Skeet [C# MVP]]

What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.

C# uses the excellent policy of making the "default" privacy level the
most private that can be used at the time. So, for instance:

class Outer
{
class Nested
{
}
}

The class Outer.Nested is private (because that's the most restrictive
access for a nested class) but class Outer is internal (because that's
the most restrictive access for a top-level class).

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

What happens if I do this:
static byte MemberFunction()
instead of:
public static byte MemberFunction()

I know I can't access it. But what does it default to? Private? I
can't find any code that does this, and "static" docs don't say much.

thanks

Zytan

Yes, they are private.

C# Language Specification - 3.5.1 Declared accessibility:

"Struct members can have public, internal, or private declared
accessibility and default to private declared accessibility because
structs are implicitly sealed."

http://msdn2.microsoft.com/en-us/library/aa691127(VS.71).aspx

 

[Zytan]

C# uses the excellent policy of making the "default" privacy level the

most private that can be used at the time. So, for instance:

class Outer
{
class Nested
{
}

}

The class Outer.Nested is private (because that's the most restrictive
access for a nested class) but class Outer is internal (because that's
the most restrictive access for a top-level class).

Jon,

great! I'll have to look up what internal means, but I know what
you're saying, and it's great that c# does this. But, i wonder why it
doesn't just force you to write the restriction attributes
explicitly? Is it common for people to rely on the default? I would
have thought no.

Zytan

 

[Zytan]

Yes, they are private.

C# Language Specification - 3.5.1 Declared accessibility:

"Struct members can have public, internal, or private declared
accessibility and default to private declared accessibility because
structs are implicitly sealed."

http://msdn2.microsoft.com/en-us/library/aa691127(VS.71).aspx

Thanks Göran!

Zytan

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I'll have to look up what internal means

It means only accessible from same assembly.

Arne

 

[Zytan]

It means only accessible from same assembly.

Arne

Ok. thanks. I was just looking this up myself:

http://msdn2.microsoft.com/en-us/library/7c5ka91b.aspx
"Internal types or members are accessible only within files in the
same assembly"

http://msdn2.microsoft.com/en-us/library/ms173099.aspx
"An assembly is a fundamental building block of any .NET Framework
application. For example, when you build a simple C# application,
Visual Studio creates an assembly in the form of a single portable
executable (PE) file, specifically an EXE or DLL."

So, any file at all in the whole project (that ends up being a single
EXE or DLL) can access something labelled 'internal', right?

Zytan

 

[Jon Skeet [C# MVP]]

great! I'll have to look up what internal means, but I know what
you're saying, and it's great that c# does this. But, i wonder why it
doesn't just force you to write the restriction attributes
explicitly? Is it common for people to rely on the default? I would
have thought no.

Personally I like relying on the defaults. In general, things should be
as private as they can be, so if I rely on the default it means that
anywhere there's an access modifier (public, internal etc) it means
I've deliberately made something more public. Different people have
different styles though.

 

[Zytan]

Personally I like relying on the defaults. In general, things should be

as private as they can be, so if I rely on the default it means that
anywhere there's an access modifier (public, internal etc) it means
I've deliberately made something more public. Different people have
different styles though.

Yes, this makes sense, once you know what the defaults are. Before I
am comfortable with what is done implicitly, I like to see the access
modifier so I know what it IS. If it's set to default, I would be
wondering what is it implicitly set to. That's why i like explicit.
Many times implicit is not a good thing.

But, now I know that I'm ok for this, since the compiler is smart.
So, your method makes sense. thanks.

Zytan

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Personally I like relying on the defaults. In general, things should be
as private as they can be, so if I rely on the default it means that
anywhere there's an access modifier (public, internal etc) it means
I've deliberately made something more public. Different people have
different styles though.

I guess a lot of people like the code to be verbose.

Especially people using multiple languages: what is
default in C# class, Java class, C++ class and C++ struct.

Arne

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I guess a lot of people like the code to be verbose.

Especially people using multiple languages: what is
default in C# class, Java class, C++ class and C++ struct.

Arne

One reason for always writing the access specifier is that then it's
visible that it's not forgotten. If one always include them, one can
easily see the difference between members that are intentionally private
and those that are accidentaly private by forgetting to specify anyting.

 

[Jon Skeet [C# MVP]]

One reason for always writing the access specifier is that then it's
visible that it's not forgotten. If one always include them, one can
easily see the difference between members that are intentionally private
and those that are accidentaly private by forgetting to specify anyting..

But because the default is the most limited, it's very rare that you
can get away with something *accidentally* being too limited - because
if you need something to be less limited, the compiler will tell you
because you'll be trying to access it from elsewhere!

 

[Zytan]

Especially people using multiple languages: what is

But because the default is the most limited, it's very rare that you
can get away with something *accidentally* being too limited - because
if you need something to be less limited, the compiler will tell you
because you'll be trying to access it from elsewhere!

You all raise good points here.

For now, I'll be verbose, since I want to see what's going on. I
don't think I'll get in trouble since I'm only using public and
private.

Good point about multiple languages. Is the default case *always* the
most limited, for all languages?

Zytan

 

[Jon Skeet [C# MVP]]

You all raise good points here.

For now, I'll be verbose, since I want to see what's going on. I
don't think I'll get in trouble since I'm only using public and
private.

I rarely use anything other than public, private and internal.

Good point about multiple languages. Is the default case *always* the
most limited, for all languages?

Definitely not. Java has an odd default (for most things) that you
can't even specify explicitly. I don't know about other .NET languages
though.

Personally I don't mind thinking differently for different languages
though - I find that if I don't, I end up with terrible code (with
incorrect use of conventions and idioms) anyway.

 

[Zytan]

I rarely use anything other than public, private and internal.

I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?

Definitely not. Java has an odd default (for most things) that you
can't even specify explicitly. I don't know about other .NET languages
though.

Ok, I thought so. Too bad.

Personally I don't mind thinking differently for different languages
though - I find that if I don't, I end up with terrible code (with
incorrect use of conventions and idioms) anyway.

Yeah, and some you have to. Imagine coding VB with arrays stated with
highest index rather than length. I'm glad I moved to C#.

Zytan

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

Good point about multiple languages. Is the default case *always* the
most limited, for all languages?

No:

C# - private = most restricted
Java - package = something in the middle
C++ class - private = most restricted
C++ struct - public = least restricted

Arne

 

[Zytan]

Good point about multiple languages. Is the default case *always* the

No:

C# - private = most restricted
Java - package = something in the middle
C++ class - private = most restricted
C++ struct - public = least restricted

Arne

Yes, I should have known, since I knew about C++ class vs struct.

Thanks Arne.

Zytan

 

[xperthands]

I know internal means visible only within the assembly. But, isn't
that the case with public? I mean, what else other than the assembly,
could see it anyway? Does it refer to linking to DLLs, where public
means the caller can see them, but internal means the DLL keeps it
hidden?

A member that is public is visible to any code that can see the class.
So if
your class is public, its public members will be visible outside of
the
assembly. If the class is internal (the default), its public members
are
visible only to other classes within the same assembly.

A member that is internal is only visible within the assembly, but to
all
code within that assembly. It is roughly equivalent to private in C++
with
all of the methods in the assembly being friends, but just for those
members.

Using protected in C# requires you to decide whether it is just
available
to derived classes in the assembly, or to all derived classes. So C#
gives you a lot more flexibility than Java.