By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,989 Members | 1,457 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,989 IT Pros & Developers. It's quick & easy.

?? Can I Limit Member Visibility to the Namespace ??

P: n/a
I understand about public, internal, protected, etc.

Is there a way to ensure members are accessible within the same
namespace only? In other words, I want to prohibit access to members
outside the namespace. Can this be done? I don't think so.

Thanks

--
Alan Foxmore
May 11 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
"Alan Foxmore" <AF******@yahoo.com> wrote:
I understand about public, internal, protected, etc.

Is there a way to ensure members are accessible within the same
namespace only? In other words, I want to prohibit access to members
outside the namespace. Can this be done? I don't think so.


Anybody can declare a class in a given namespace, so such a restriction
wouldn't be particularly useful. Internal visibility is useful, on the
other hand.

-- Barry
May 11 '06 #2

P: n/a
On Thu, 11 May 2006 13:05:01 -0500, Alan Foxmore wrote:
I understand about public, internal, protected, etc.

Is there a way to ensure members are accessible within the same
namespace only? In other words, I want to prohibit access to members
outside the namespace. Can this be done? I don't think so.


No, that can't be done. Place your namespace alone in an assembly and use
internal.
May 11 '06 #3

P: n/a
Alan,
Is there a way to ensure members are accessible within the same
namespace only? In other words, I want to prohibit access to members
outside the namespace. Can this be done? I don't think so.


No, and I don't see why it would be useful since anyone can add types
to any namespace.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.
May 11 '06 #4

P: n/a

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:9b********************************@4ax.com...
"Alan Foxmore" <AF******@yahoo.com> wrote:
I understand about public, internal, protected, etc.

Is there a way to ensure members are accessible within the same
namespace only? In other words, I want to prohibit access to members
outside the namespace. Can this be done? I don't think so.


Anybody can declare a class in a given namespace, so such a
restriction
wouldn't be particularly useful. Internal visibility is useful, on
the
other hand.


Yes, of course -- that makes complete sense.

Thanks!
--
Alan Foxmore
May 11 '06 #5

P: n/a
Mattias Sjögren <ma********************@mvps.org> wrote:
Is there a way to ensure members are accessible within the same
namespace only? In other words, I want to prohibit access to members
outside the namespace. Can this be done? I don't think so.


No, and I don't see why it would be useful since anyone can add types
to any namespace.


Well, that's another thing you'd want to limit if you gave the ability
to have this level of protection.

I suspect the OP is a Java programmer - Java has this restriction (or
at least something like it) and Java allows you to have jar files which
"seal" a package, so no other jar file can contribute classes to it
(within the same classloader).

Personally I like the idea - sometimes you don't want everything within
a particular assembly to have access to all the internal members of a
type. On the other hand, there are quite enough access modifiers
already - does anyone actually use "protected internal" for instance?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
May 11 '06 #6

P: n/a
Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
type. On the other hand, there are quite enough access modifiers
already - does anyone actually use "protected internal" for instance?


I do, occasionally, in certain circumstances, for a particular pattern
that I implement.

It could equally have been implemented with two methods, one internal
calling the other, protected. It one way, the access modifier could be
seen as redundant, in the same way as default parameters are redundant
when you already have overloads.

-- Barry
May 11 '06 #7

P: n/a
> does anyone actually use "protected internal" for instance?

I've used it one or two times. But I never felt great about the design of
what I was writing when I needed it. :-)

Best Regards,
Dustin Campbell
Developer Express Inc
May 11 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.