Question of a Java programmer

[Martin Pöpping]

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

[ssamuel@gmail.com]

Re: Question of a Java programmer

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



Martin Pöpping wrote:

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]

Re: Question of a Java programmer

Martin Pöpping wrote:

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.
--
Tom Porterfield

[Martin Pöpping]

Re: Question of a Java programmer

ssamuel@gmail.c om schrieb:

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]

Re: Question of a Java programmer


Martin Pöpping wrote:

ssamuel@gmail.c om schrieb:
>

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?

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]]

Re: Question of a Java programmer

Martin Pöpping wrote:

ssamuel@gmail.c om schrieb:
>

>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?

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]

Re: Question of a Java programmer


"Martin Pöpping" <martin_p@despa mmed.comwrote in message
news:ehl7ck$aju $1@newsreader2. netcologne.de.. .

ssamuel@gmail.c om schrieb:
>

>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?

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]]

Re: Question of a Java programmer

Martin Pöpping <martin_p@despa mmed.comwrote:

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...

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Arne Vajhøj]

Re: Question of a Java programmer

Jon Skeet [C# MVP] wrote:

Martin Pöpping <martin_p@despa mmed.comwrote:

>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...

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

Arne

[Jon Skeet [C# MVP]]

Re: Question of a Java programmer

Arne Vajhøj <arne@vajhoej.d kwrote:

Jon Skeet [C# MVP] wrote:

Martin Pöpping <martin_p@despa mmed.comwrote:

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...

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.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Arne Vajhøj]

Re: Question of a Java programmer

Jon Skeet [C# MVP] wrote:

Arne Vajhøj <arne@vajhoej.d kwrote:

>Jon Skeet [C# MVP] wrote:

>>Martin Pöpping <martin_p@despa mmed.comwrote:
>>>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...

>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.

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]]

Re: Question of a Java programmer

Arne Vajhøj <arne@vajhoej.d kwrote:

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).

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

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Laurent Bugnion]

Re: Question of a Java programmer

Hi,

Jon Skeet [C# MVP] wrote:

Arne Vajhøj <arne@vajhoej.d kwrote:

>>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) .

>
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.dl l contains MyFirm.Hello
namespace as well as MyFirm.Hello.Wo rld and MyFirm.Hello.Ag ain.

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
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch

[Jon Skeet [C# MVP]]

Re: Question of a Java programmer

Laurent Bugnion <galasoft-lb@bluewin.chwr ote:

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.

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.dl l contains MyFirm.Hello
namespace as well as MyFirm.Hello.Wo rld and MyFirm.Hello.Ag ain.
>
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.

--
Jon Skeet - <skeet@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Laurent Bugnion]

Re: Question of a Java programmer

Hi,

Jon Skeet [C# MVP] wrote:

>
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?

>For example, the assembly MyFirm.Hello.dl l contains MyFirm.Hello
>namespace as well as MyFirm.Hello.Wo rld and MyFirm.Hello.Ag ain.
>>
>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.

I'll take your word on that.

Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
PhotoAlbum: http://www.galasoft-LB.ch/pictures
Support children in Calcutta: http://www.calcutta-espoir.ch