Private vs Non-Public

[Paul]

Hello All,

I am new to C# and dot NET in general. The book I am reading uses the
term "non-public."
I suspect that they don't mean "private", otherwise they would have
said so. What is the difference between "non-public" and "private"?

Help is always appreciated. Thanks,

Paul

[Barry Kelly]

"Paul" <he********@yahoo.ca> wrote:

I am new to C# and dot NET in general. The book I am reading uses the
term "non-public."
I suspect that they don't mean "private", otherwise they would have
said so. What is the difference between "non-public" and "private"?

"protected" and "internal" are the two other non-public visibilities.

"internal" members and types are visible only to other types in the same
assembly (i.e. same .exe file or same .dll file). When you declare a
class without any visibility specifier, it means the class is internal,
for example. Class members without a visibility specifier are private,
however. Internal is useful to allow two classes in a class library to
communicate with each other, and simultaneously prevent end-user code
from interfering with this communication (because the methods etc. in
question would be marked internal, and wouldn't be available outside the
assembly).

"protected" members are visible only within the type and its
descendants. This allows special communication along the inheritance
hierarchy, but disallows "outsider" class access.

Note that if a constructor for a non-sealed class which declares the
"protected" members is public or protected, then any descendant can
derive from it, and so "protected" in that case doesn't act as any kind
of "security" mechanism for classes that live in class libraries. For
this reason, protected members require just as much care and parameter
error checking as public members (if not more care).

-- Barry

--
http://barrkel.blogspot.com/

[Mark Wilden]

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:nm********************************@4ax.com...

"protected" and "internal" are the two other non-public visibilities.

Also, "protected internal" is a kind of accessibility, presumably to make it
clear that "private internal," etc., is not allowed.

///ark

[Barry Kelly]

"Mark Wilden" <Ma********@newsgroups.nospam> wrote:

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:nm********************************@4ax.com...

"protected" and "internal" are the two other non-public visibilities.

Also, "protected internal" is a kind of accessibility, presumably to make it
clear that "private internal," etc., is not allowed.

Yes, that guy slipped my mind.

-- Barry

--
http://barrkel.blogspot.com/

[Mark Wilden]

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:7f********************************@4ax.com...

Also, "protected internal" is a kind of accessibility, presumably to make
it
clear that "private internal," etc., is not allowed.

Yes, that guy slipped my mind.

I've never used protected internal -- have you?

[Barry Kelly]

"Mark Wilden" <Ma********@newsgroups.nospam> wrote:

"Barry Kelly" <ba***********@gmail.com> wrote in message
news:7f********************************@4ax.com...

Also, "protected internal" is a kind of accessibility, presumably to make
it
clear that "private internal," etc., is not allowed.

Yes, that guy slipped my mind.

I've never used protected internal -- have you?

I have, but not often. Trivially: it's never more powerful than having
an existing protected method, and then writing an internal method to
forward to the protected method.

The circumstances I've used it appear to mostly be for virtual or
abstract methods that need to be overridden, but shouldn't form part of
the public interface of a class, yet need to be called by other classes
in the same assembly or "eco-system".

One example I have on my disk right now: I had a simple visual tree
framework once (i.e. a hierarchical render tree), and each element in
the visual tree had a Render method which accepted a Renderer argument.
The renderer actually visited the tree, and was the only guy who could
legitimately call the method:

protected internal virtual void Render(Renderer r) { ... }

There were other methods along similar lines, for layout etc. IIRC. It's
been some time since I looked at it; it was an experiment when I first
found out about Avalon, and it never got finished.

-- Barry

--
http://barrkel.blogspot.com/