Question of a Java programmer

[Guest]

Hello,

I´m relatively new in programming with C#.

I want to design a class with can only be used in the same namespace.

So I declared this class as protected, but the compiler gives me the
following error:

Error 1 Namespace elements cannot be explicitly declared as private,
protected, or protected internal [...]

How can I reach my aim?
When do you use "protected" if not to declare a class only for
the use in the same namespace?


Regards,

Martin

 

[Tom Porterfield]

Hello,

I´m relatively new in programming with C#.

I want to design a class with can only be used in the same namespace.

So I declared this class as protected, but the compiler gives me the
following error:

Error 1 Namespace elements cannot be explicitly declared as private,
protected, or protected internal [...]

How can I reach my aim?
When do you use "protected" if not to declare a class only for
the use in the same namespace?

Protected means the item is only available to the current class and any
derived classes. There is no declaration that limits scope to the current
namespace. You can use "internal" to limit scope to the current assembly.

But you don't apply that directly to the class if it is at the namespace
level. You could make the constructor internal which would limit the
ability to create an instance of the class to only the assembly that
contains the class. Ex:

namespace MyNamespace
{
class MyClass
{
internal MyClass(){}
}
}

The distinction is important as you can have more than one namespace in an
assembly, and the same namespace can be in multiple assemblies. Internal
limits the scope to the assembly.

 

[ssamuel]

Martin,

You can't strictly do this in C#. However, the internal keyword marks a
class as visible to other widgets within the same assembly. An assembly
is similar to a package: it represents one DLL or EXE. If you're using
VS.NET, an assembly is one project; it can contain more than one
namespace.

I intuit that this was done to delimit the edges of a distributable
package, similar to the way it looks in Java. That is, you distribute a
binary assembly (DLL or EXE) to a customer, and it may contain one or
more namespaces. Internal elements within it are visible only to you,
and you make public what you want consumers of your library to see. An
examble is mscorlib.dll, the main .NET framework library, which
contains many but not all of the System.* namespaces.


Stephan

 

[=?ISO-8859-1?Q?Martin_P=F6pping?=]

You can't strictly do this in C#. However, the internal keyword marks a
class as visible to other widgets within the same assembly. An assembly
is similar to a package: it represents one DLL or EXE. If you're using
VS.NET, an assembly is one project; it can contain more than one
namespace.

Thanks for your answer. It sounds clear now.

So I cannot make a class only accessible in one namespace in another way?


Regards,

Martin

 

[Bruce Wood]

Thanks for your answer. It sounds clear now.

So I cannot make a class only accessible in one namespace in another way?

Nope. The two languages (Java and C#) have slightly different concepts
of scope at the namespace / distributable package level. You have to
adapt your scoping strategy accordingly.

 

[Carl Daniel [VC++ MVP]]

Thanks for your answer. It sounds clear now.

So I cannot make a class only accessible in one namespace in another
way?

No, you cannot. Class visibility for top level classes is limited to public
(everyone can see) and internal (same assembly can see). Under .NET, a
namespace is nothing more than decoration on a name - it has no structural
or access-limiting qualities at all.

-cd

 

[PS]

Thanks for your answer. It sounds clear now.

So I cannot make a class only accessible in one namespace in another way?

No, but you can do what you want by wrapping your classes within a class and
using private constructors. The classes are only available to use from
within the outermost class.

public class Open
{
// Class1 or 2 is not available here
}

public partial class Closed
{
private class Class1
{
Class2 c2 = new Class2();
}
}

public partial class Closed
{
private class Class2
{
Class1 c1 = new Class1();
}
}

PS

 

[Jon Skeet [C# MVP]]

So I cannot make a class only accessible in one namespace in another way?

No, unfortunately not. It's irritating, because sometimes when I'm
writing C# I want namespace-level access, and often when I'm writing
Java I want the concept of an assembly and the equivalent of
"internal" access restrictions. Then again, adding yet another access
modifier would make things more confusing...

 

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

No, unfortunately not. It's irritating, because sometimes when I'm
writing C# I want namespace-level access, and often when I'm writing
Java I want the concept of an assembly and the equivalent of
"internal" access restrictions. Then again, adding yet another access
modifier would make things more confusing...

one namespace === one assembly => package ~=== internal

Arne

 

[Jon Skeet [C# MVP]]

one namespace === one assembly => package ~=== internal

Well, I'm not at all sure what you meant there, but namespaces are
similar to packages, but there really *isn't* a concept like an
assembly in Java. You *can* add metadata to a jar file saying that no
other jar files are allowed to add to a namespace, but it's not
commonly used.

 

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

Well, I'm not at all sure what you meant there, but namespaces are
similar to packages, but there really *isn't* a concept like an
assembly in Java. You *can* add metadata to a jar file saying that no
other jar files are allowed to add to a namespace, but it's not
commonly used.

I mean that if you follow a coding convention of a 1:1
relation ship between namespace and assembly, then internal
access will be like java package accessibility (well - actually
it should be internal protected, but I would prefer internal
any time - I consider that feature of Java highly
undesirable).

Arne

 

[Jon Skeet [C# MVP]]

I mean that if you follow a coding convention of a 1:1
relation ship between namespace and assembly, then internal
access will be like java package accessibility (well - actually
it should be internal protected, but I would prefer internal
any time - I consider that feature of Java highly
undesirable).

Right. I see what you mean. Such a coding convention would be
incredibly restrictive though

 

[Laurent Bugnion]

Hi,

Right. I see what you mean. Such a coding convention would be
incredibly restrictive though

Not necessarily. In our guidelines, an assembly may include one
namespace and the descendants of this namespace.

For example, the assembly MyFirm.Hello.dll contains MyFirm.Hello
namespace as well as MyFirm.Hello.World and MyFirm.Hello.Again.

This guideline has a huge advantage in our opinion: It makes debugging
much faster in big projects. When you get an error, you can find the
faulty module very easily, and don't have to look through all components.

Of course, as with every guideline, exceptions are allowed if duly
documented.

HTH,
Laurent

 

[Jon Skeet [C# MVP]]

Not necessarily. In our guidelines, an assembly may include one
namespace and the descendants of this namespace.

At that point, however, you don't have the "one assembly to one
namespace" correlation - you have "one assembly to several namespaces".

For example, the assembly MyFirm.Hello.dll contains MyFirm.Hello
namespace as well as MyFirm.Hello.World and MyFirm.Hello.Again.

This guideline has a huge advantage in our opinion: It makes debugging
much faster in big projects. When you get an error, you can find the
faulty module very easily, and don't have to look through all components.

Frankly, it's Visual Studio's fault that it's not easy to get to a
specified type very quickly, regardless of the number of projects. In
Eclipse it's absolutely trivial.

 

[Laurent Bugnion]

Hi,

At that point, however, you don't have the "one assembly to one
namespace" correlation - you have "one assembly to several namespaces".

I think it's what Arne meant, but I might be wrong. In Java, IIRC, the
"package" visibility also applies to sub-packages. So even if you have
sub namespaces in an assembly, Arne's post still make sense, am I wrong?

Frankly, it's Visual Studio's fault that it's not easy to get to a
specified type very quickly, regardless of the number of projects. In
Eclipse it's absolutely trivial.

I'll take your word on that.

Laurent

 

[Jon Skeet [C# MVP]]

I think it's what Arne meant, but I might be wrong. In Java, IIRC, the
"package" visibility also applies to sub-packages. So even if you have
sub namespaces in an assembly, Arne's post still make sense, am I wrong?

You're absolutely right - my apologies. I'd forgotten the bizarre
subpackage rule, which makes no sense at all in my view - for the rest
of Java, a subpackage has no relationship to its parent package. Ah
well...

I'll take your word on that.

Basically you hit Ctrl-Shift-T and start typing in the type name - it
displays a live list, giving you package options for types in multiple
packages. You don't even have to type the whole name - type MCC and it
will offer MyCoolClass, for instance.

 

[Jon Skeet [C# MVP]]

I think it's what Arne meant, but I might be wrong. In Java, IIRC, the
"package" visibility also applies to sub-packages. So even if you have
sub namespaces in an assembly, Arne's post still make sense, am I wrong?

Hang on - I retract my apologies a bit. The rule isn't that silly after
all - I was misreading a bit of the spec in my haste.

If you have:

package parent;

class Foo
{
}

....

package parent.child;
import parent.Foo;

class Bar
{
Foo f;
}

then you'll get a compilation error. Likewise change Foo to have a Bar
member and you'll get a compilation error.

So it looks like Java is sensible after all in that particular
respoect, but you would *really* have to have just one package - and
even then you'd have the nastiness that Java's default access includes
protected access (goodness knows why).

 

[Samuel R. Neff]

You can do this type of navigation in Visual Studio with the Resharper
plugin (and a whole lot of other stuff). ReSharper makes VS much
better.

http://www.jetbrains.com/resharper/features/NavSearch.html

Sam


------------------------------------------------------------
We're hiring! B-Line Medical is seeking Mid/Sr. .NET
Developers for exciting positions in medical product
development in MD/DC. Work with a variety of technologies
in a relaxed team environment. See ads on Dice.com.

 

[Mark Wilden]

Frankly, it's Visual Studio's fault that it's not easy to get to a
specified type very quickly, regardless of the number of projects. In
Eclipse it's absolutely trivial.

It's also trivial to get to a type very quickly using ReSharper, a sine qua
non for VSS development in my opinion.

///ark

 

[Jon Skeet [C# MVP]]

You can do this type of navigation in Visual Studio with the Resharper
plugin (and a whole lot of other stuff). ReSharper makes VS much
better.

http://www.jetbrains.com/resharper/features/NavSearch.html

I tried it a while ago and liked it - apart from the way that it takes
ages to find all the types the first time you use it on a solution
after loading Visual Studio. (Not just once, but *every* time you load
Visual Studio.)

If it cached the results and just updated itself in the background,
that would be fine - but it doesn't.

Seriously though, Visual Studio ought to offer this kind of thing out
of the box. I've always thought MS should spend more time making
*actual coding* easier (i.e. time spent in the plain code editors) and
less time making designers fancier.