Plans for Internal (C#) / Friend (VB.Net) And Protected ?

[Carlos J. Quintero]

Hi,

As you know the current keywords "protected internal" (C#) or "Protected
Friend" (VB.Net) means "Protected Or internal" (C#) or "Protected Or Friend"
(VB.Net), that is, the member is accesible from whichever types inside the
assembly or from derived classes included those outside the assembly.

The IL has a provision for the "family AND assembly" accesibility level,
that is, a member is accesible from derived classes belonging to the
assembly, but not from derived classes outside it. But it seems that neither
VB.Net not C# have keywords for it, only for the IL "family OR assembly"
accesibility level. Can someone (maybe from MS) tell if there are plans for
them in future versions of those .Net languages?

Thanks in advance

Carlos Quintero

[Nicholas Paldino [.NET/C# MVP]]

Carlos,

As a general rule, you won't get a response on this kind of thing unless
it has been previously released. The general catch phrase is "I am not able
to comment on future features or functionality". I haven't seen anything in
any papers anywhere indicating that this is the case.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- ni**************@exisconsulting.com

"Carlos J. Quintero" <carlos_j_quintero@_NO_MORE_SPAM_hotmail.com> wrote in
message news:%2******************@TK2MSFTNGP10.phx.gbl...

Hi,

As you know the current keywords "protected internal" (C#) or "Protected
Friend" (VB.Net) means "Protected Or internal" (C#) or "Protected Or Friend" (VB.Net), that is, the member is accesible from whichever types inside the
assembly or from derived classes included those outside the assembly.

The IL has a provision for the "family AND assembly" accesibility level,
that is, a member is accesible from derived classes belonging to the
assembly, but not from derived classes outside it. But it seems that neither VB.Net not C# have keywords for it, only for the IL "family OR assembly"
accesibility level. Can someone (maybe from MS) tell if there are plans for them in future versions of those .Net languages?

Thanks in advance

Carlos Quintero

[Jay B. Harlow [MVP - Outlook]]

Carlos,
In addition to Nicholas's comments. The best source of info (that I know of)
on what will be included in future versions of VS.NET can be found at:

http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx

Hope this helps
Jay

"Carlos J. Quintero" <carlos_j_quintero@_NO_MORE_SPAM_hotmail.com> wrote in
message news:%2******************@TK2MSFTNGP10.phx.gbl...

Hi,

As you know the current keywords "protected internal" (C#) or "Protected
Friend" (VB.Net) means "Protected Or internal" (C#) or "Protected Or Friend" (VB.Net), that is, the member is accesible from whichever types inside the
assembly or from derived classes included those outside the assembly.

The IL has a provision for the "family AND assembly" accesibility level,
that is, a member is accesible from derived classes belonging to the
assembly, but not from derived classes outside it. But it seems that neither VB.Net not C# have keywords for it, only for the IL "family OR assembly"
accesibility level. Can someone (maybe from MS) tell if there are plans for them in future versions of those .Net languages?

Thanks in advance

Carlos Quintero

[Eric Gunnerson [MS]]

Carlos,

Can you describe the scenario in which you'd like to use this?

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
"Carlos J. Quintero" <carlos_j_quintero@_NO_MORE_SPAM_hotmail.com> wrote in
message news:%2******************@TK2MSFTNGP10.phx.gbl...

Hi,

As you know the current keywords "protected internal" (C#) or "Protected
Friend" (VB.Net) means "Protected Or internal" (C#) or "Protected Or Friend" (VB.Net), that is, the member is accesible from whichever types inside the
assembly or from derived classes included those outside the assembly.

The IL has a provision for the "family AND assembly" accesibility level,
that is, a member is accesible from derived classes belonging to the
assembly, but not from derived classes outside it. But it seems that neither VB.Net not C# have keywords for it, only for the IL "family OR assembly"
accesibility level. Can someone (maybe from MS) tell if there are plans for them in future versions of those .Net languages?

Thanks in advance

Carlos Quintero

[Carlos J. Quintero]

Suppose that you have a control (or whatever kind of entity) library in an
assembly. All the controls of the library are derived from a base class.
Furthermore, you want to offer the chance of others to build controls
derived from the base class of your control library but you want to expose
only a subset of the methods of the base class to "external" controls, that
is, "internal" controls of the library take advantage of some methods of the
base class that for whatever reasons you don´t want to offer to "external"
controls. Currently you have two options:

1) Make another base class with friend (internal) scope derived from the
public one, move the methods available only to "internal" controls to it and
derive the "internal" controls from it instead of from the original base
class. But those methods may need to call private methods of the original
base class that now are not accessible to them...

2) Change the scope of methods only available to "internal" controls from
protected to friend (internal). This hides the methods to "external"
controls but exposes them to classes inside the assembly that are not
derived from the base class, which is not 100% ideal.

So, what is needed in this scenario is an accesibility level of "Protected
And Internal" (meaning "Protected INTERSECT Internal") and I discovered that
the IL has it ("Family And Assembly"), but it seems that .Net languages such
VB.Net or C# don´t implement it, maybe because it was not considered useful
in most cases or maybe because it would be a problem to choose keywords for
"Protected INTERSECT Internal" and "Protected UNION Internal" accesibilty
levels. The current keyword pair "protected internal" means "Protected UNION
Internal" but it is not obvious, and when searching about this in Internet I
have seen early posts, even from MS people, that was confused thinking it
meant "Protected INTERSECT Internal"...

I hope this explains one of the scenarios where it would be nice to have
that accesibility level.

Carlos Quintero

"Eric Gunnerson [MS]" <er****@online.microsoft.com> escribió en el mensaje
news:ex**************@tk2msftngp13.phx.gbl...

Carlos,

Can you describe the scenario in which you'd like to use this?

--
Eric Gunnerson

[Carlos J. Quintero]

Thanks Nicholas, but you know that MS makes public some features even before
the first betas, such partial types, operator overloading for VB.Net, etc.
as published in http://msdn.microsoft.com/vstudio/pr...o/roadmap.aspx.
I just wanted to know if there was some news that I may have missed about my
topic and/or to bring some attention from MS about it.

Best regards,

Carlos Quintero

"Nicholas Paldino [.NET/C# MVP]" <ni**************@exisconsulting.com>
escribió en el mensaje news:%2****************@TK2MSFTNGP12.phx.gbl...

Carlos,

As a general rule, you won't get a response on this kind of thing unless it has been previously released. The general catch phrase is "I am not able to comment on future features or functionality". I haven't seen anything in any papers anywhere indicating that this is the case.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- ni**************@exisconsulting.com

[Stu Smith]

I always worry about the internal specifier as it violates the
0..1..infinity guideline. Private allows one class access; public and
protected allow (potentially) infinite number of classes to access, but
internal allows a small number of classes within the assembly access -- ie
not one or infinite.

(Examples of problems which could have been avoided by following this
guideline are:
DOS 8.3 names; solved by new long filenames;
Fixed-buffer overrun vulnerabilities; solved by using classes like
CString etc)

Just one of those guidelines I continually fail to follow, and then get
bitten by later.

Stu
"Carlos J. Quintero" <carlos_j_quintero@_NO_MORE_SPAM_hotmail.com> wrote in
message news:uO****************@tk2msftngp13.phx.gbl...

Suppose that you have a control (or whatever kind of entity) library in an
assembly. All the controls of the library are derived from a base class.
Furthermore, you want to offer the chance of others to build controls
derived from the base class of your control library but you want to expose
only a subset of the methods of the base class to "external" controls, that is, "internal" controls of the library take advantage of some methods of the base class that for whatever reasons you don´t want to offer to "external"
controls. Currently you have two options:

1) Make another base class with friend (internal) scope derived from the
public one, move the methods available only to "internal" controls to it and derive the "internal" controls from it instead of from the original base
class. But those methods may need to call private methods of the original
base class that now are not accessible to them...

2) Change the scope of methods only available to "internal" controls from
protected to friend (internal). This hides the methods to "external"
controls but exposes them to classes inside the assembly that are not
derived from the base class, which is not 100% ideal.

So, what is needed in this scenario is an accesibility level of "Protected
And Internal" (meaning "Protected INTERSECT Internal") and I discovered that the IL has it ("Family And Assembly"), but it seems that .Net languages such VB.Net or C# don´t implement it, maybe because it was not considered useful in most cases or maybe because it would be a problem to choose keywords for "Protected INTERSECT Internal" and "Protected UNION Internal" accesibilty
levels. The current keyword pair "protected internal" means "Protected UNION Internal" but it is not obvious, and when searching about this in Internet I have seen early posts, even from MS people, that was confused thinking it
meant "Protected INTERSECT Internal"...

I hope this explains one of the scenarios where it would be nice to have
that accesibility level.

Carlos Quintero

"Eric Gunnerson [MS]" <er****@online.microsoft.com> escribió en el mensaje
news:ex**************@tk2msftngp13.phx.gbl...

Carlos,

Can you describe the scenario in which you'd like to use this?

--
Eric Gunnerson

[Carlos J. Quintero]

I have not heard about that guideline, but for me it does not apply to the
current world of software components, maybe when all were .EXEs and there
was reuse of source code but not of compiled code... precisely with the
"internal" scope you are not bitten if you made some mistake when developing
a component because you change it internally and nothing is noticed from the
outside. The scope "internal and protected" scope that I was talking about
is in the same line. If you expand the scope to "protected" or (even worse)
to "public" when is not really needed, you have even many more chances to
get bitten later, in my opinion...

Best regards,

Carlos Quintero

"Stu Smith" <st*****@remove.digita.com> escribió en el mensaje
news:%2****************@TK2MSFTNGP12.phx.gbl...

I always worry about the internal specifier as it violates the
0..1..infinity guideline. Private allows one class access; public and
protected allow (potentially) infinite number of classes to access, but
internal allows a small number of classes within the assembly access -- ie
not one or infinite.

(Examples of problems which could have been avoided by following this
guideline are:
DOS 8.3 names; solved by new long filenames;
Fixed-buffer overrun vulnerabilities; solved by using classes like
CString etc)

Just one of those guidelines I continually fail to follow, and then get
bitten by later.

Stu

[Stu Smith]

Oh, agreed there are uses for it. I tend to get annoyed though when I'm
using a library if too much is internal for no apparent reason (eg
WindowsForms). I also tend to find that if I use internal, I often come back
later and realise I could have done it a better way. Internal if not used
correctly can lead to fairly spaghetti-fied code.

Not criticising here btw, I just find it a useful guideline.

And before anyone asks for examples in WindowsForms, here's one:

LinkLabel: why can't I change its painting behaviour? The PaintXXX methods
are all private. The GetStringFormat is private. I can't change any aspect
of this control's behaviour or appearance without rewriting large swathes of
code, and that annoys me. I'd consider that lazy component design.

Anyway, that's a little off-topic, so apologies.

Stu (rant over)
"Carlos J. Quintero" <carlos_j_quintero@_NO_MORE_SPAM_hotmail.com> wrote in
message news:eF*************@tk2msftngp13.phx.gbl...

I have not heard about that guideline, but for me it does not apply to the
current world of software components, maybe when all were .EXEs and there
was reuse of source code but not of compiled code... precisely with the
"internal" scope you are not bitten if you made some mistake when developing a component because you change it internally and nothing is noticed from the outside. The scope "internal and protected" scope that I was talking about
is in the same line. If you expand the scope to "protected" or (even worse) to "public" when is not really needed, you have even many more chances to
get bitten later, in my opinion...

Best regards,

Carlos Quintero

"Stu Smith" <st*****@remove.digita.com> escribió en el mensaje
news:%2****************@TK2MSFTNGP12.phx.gbl...

I always worry about the internal specifier as it violates the
0..1..infinity guideline. Private allows one class access; public and
protected allow (potentially) infinite number of classes to access, but
internal allows a small number of classes within the assembly access -- ie not one or infinite.

(Examples of problems which could have been avoided by following this
guideline are:
DOS 8.3 names; solved by new long filenames;
Fixed-buffer overrun vulnerabilities; solved by using classes like
CString etc)

Just one of those guidelines I continually fail to follow, and then get
bitten by later.

Stu