internal class, public members?

[Andrew R. Thomas-Cramer]

Can I simply mark a class as internal, or should I change all its public
members to internal as well?

If I can mark the class only as internal, it makes modifications easy.

[Jon Skeet]

Andrew R. Thomas-Cramer <ar**@shell.core.com> wrote:

Can I simply mark a class as internal, or should I change all its public
members to internal as well?

If I can mark the class only as internal, it makes modifications easy.

You can certainly mark a class as internal, but that's different from
making its public members internal. For instance, suppose you have a
class which implements a public interface. Even though the class may be
internal, an instance may still "get out of the assembly" by being
returned from a member in another (public) class. That instance would
have to be referenced by the interface it implements rather than the
class name itself (as the class isn't known to the outside assembly)
but the public methods can still be called.

If the public methods aren't implementing any interfaces, I suspect it
would only make a difference in a very few reflection cases which you
may not care about.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Chris Taylor]

lol, I considered mentioning nested classes, but thought this was a good
enough starting point. Should have mentioned those. Thanks.
"Jon Skeet" <sk***@pobox.com> wrote in message
news:MP************************@news.microsoft.com ...

Chris Taylor <ch*************@hotmail.com> wrote:

An internal class can have public members, internal is the default for
classes when no access modifier is specified.

... with the slight wrinkle that a type declared within another type
(example below) defaults to private.

public class Foo
{
class Nested // Defaults to private
{
}
}

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Andrew R. Thomas-Cramer]

Jon Skeet <sk***@pobox.com> writes:

If the public methods aren't implementing any interfaces, I suspect it
would only make a difference in a very few reflection cases which you
may not care about.

In this case the assembly is being produced for a large corporation, may
be shared with partners, and will be distributed at thousands of sites
around the world. I'm curious what those reflection cases are. :)

[Jon Skeet]

Andrew R. Thomas-Cramer <ar**@shell.core.com> wrote:

Jon Skeet <sk***@pobox.com> writes:

If the public methods aren't implementing any interfaces, I suspect it
would only make a difference in a very few reflection cases which you
may not care about.

In this case the assembly is being produced for a large corporation, may
be shared with partners, and will be distributed at thousands of sites
around the world. I'm curious what those reflection cases are. :)

Fair enough. At this stage however I'm going into speculation...

I don't know exactly how the security over reflection works - but with
appropriately lax security settings, it's quite possible to interrogate
the internal types, and if an internal type has a public constructor,
you may even be able to instantiate it and call public methods on it
(again with reflection) where if those methods were internal, there
*may* be some situations where you could get the Type reference, but
not instantiate the type or call the methods.

Do you see what I mean, or do you want me to try to clarify that pretty
hideous sentence?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet/
If replying to the group, please do not mail me too

[Andrew R. Thomas-Cramer]

Jon Skeet <sk***@pobox.com> writes:

Do you see what I mean, or do you want me to try to clarify that pretty
hideous sentence?

I get it. Thanks!