Internal vs friend (C++)

Re: Internal vs friend (C++)

Jesper,

The only way that the internal keyword is going to help is if both
classes are defined in the same assembly. If they are, then internal fields
are able to be seen by any of the classes in the same assembly. The only
other option you have is protected, which forces you to derive from a base
class to see protected members.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m


"Jesper" <anonymous@disc ussions.microso ft.com> wrote in message
news:045b01c3db 70$1e5c9570$a00 1280a@phx.gbl.. .[color=blue]
> I need to grant a class access to protected fields of
> another class in the way its possible in C++ with the
> friend keyword. However I would like to keep the class
> protected towards other class within the same
> program/assembly. The two classes are not 'related'
> (inherited).
>
> How can I do this. I cant see how the keyword Internal
> can be used for this purpose.
>
> best regards Jesper.
>[/color]

Re: Internal vs friend (C++)

Do you know why this functionality (friend)is discarded
in C#, is it to be implemented in another way?
[color=blue]
>-----Original Message-----
>Jesper,
>
> The only way that the internal keyword is going to[/color]
help is if both[color=blue]
>classes are defined in the same assembly. If they are,[/color]
then internal fields[color=blue]
>are able to be seen by any of the classes in the same[/color]
assembly. The only[color=blue]
>other option you have is protected, which forces you to[/color]
derive from a base[color=blue]
>class to see protected members.
>
> Hope this helps.
>
>
>--
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard. caspershouse.co m
>
>
>"Jesper" <anonymous@disc ussions.microso ft.com> wrote in[/color]
message[color=blue]
>news:045b01c3d b70$1e5c9570$a0 01280a@phx.gbl. ..[color=green]
>> I need to grant a class access to protected fields of
>> another class in the way its possible in C++ with the
>> friend keyword. However I would like to keep the class
>> protected towards other class within the same
>> program/assembly. The two classes are not 'related'
>> (inherited).
>>
>> How can I do this. I cant see how the keyword Internal
>> can be used for this purpose.
>>
>> best regards Jesper.
>>[/color]
>
>
>.
>[/color]

Re: Internal vs friend (C++)

Jesper,

It was never discarded. C# is not meant to be an extension or a
variation on C++. It is a new language, and this functionality is simply
just not there.

As for why it is not there, I imagine that the original language
designers didn't see much use for it. Also, given that the language has
been in use for a few years now and there hasn't been any huge outcry over
it, I would think that it serves as validation of their decision. I'm not
saying it is right or wrong, just that it is not there, and no one is really
complaining about it.

What exactly are you looking to achieve?


--
- Nicholas Paldino [.NET/C# MVP]
- mvp@spam.guard. caspershouse.co m

"Jesper" <anonymous@disc ussions.microso ft.com> wrote in message
news:0ca801c3db 72$be5df850$a30 1280a@phx.gbl.. .[color=blue]
> Do you know why this functionality (friend)is discarded
> in C#, is it to be implemented in another way?
>[color=green]
> >-----Original Message-----
> >Jesper,
> >
> > The only way that the internal keyword is going to[/color]
> help is if both[color=green]
> >classes are defined in the same assembly. If they are,[/color]
> then internal fields[color=green]
> >are able to be seen by any of the classes in the same[/color]
> assembly. The only[color=green]
> >other option you have is protected, which forces you to[/color]
> derive from a base[color=green]
> >class to see protected members.
> >
> > Hope this helps.
> >
> >
> >--
> > - Nicholas Paldino [.NET/C# MVP]
> > - mvp@spam.guard. caspershouse.co m
> >
> >
> >"Jesper" <anonymous@disc ussions.microso ft.com> wrote in[/color]
> message[color=green]
> >news:045b01c3d b70$1e5c9570$a0 01280a@phx.gbl. ..[color=darkred]
> >> I need to grant a class access to protected fields of
> >> another class in the way its possible in C++ with the
> >> friend keyword. However I would like to keep the class
> >> protected towards other class within the same
> >> program/assembly. The two classes are not 'related'
> >> (inherited).
> >>
> >> How can I do this. I cant see how the keyword Internal
> >> can be used for this purpose.
> >>
> >> best regards Jesper.
> >>[/color]
> >
> >
> >.
> >[/color][/color]

Re: Internal vs friend (C++)

Something like this, where I assert that an object is of
a certain type in order to get access to a member of the
class. Class2 cannot be inherited from Class1.

class Class1
{
protected int i;

Set_I(int i,object obj)
{
if (obj is Class2)
{
this.i = i;
}
}
}

If Class2 is a friend of Class1, I would not need to
write a setter. Moreover I would get errors at compile
time if I try to access the class from a class that is
not a friend.

by the way, thanks for answering
brgds Jesper.

[color=blue]
>-----Original Message-----
>Jesper,
>
> It was never discarded. C# is not meant to be an[/color]
extension or a[color=blue]
>variation on C++. It is a new language, and this[/color]
functionality is simply[color=blue]
>just not there.
>
> As for why it is not there, I imagine that the[/color]
original language[color=blue]
>designers didn't see much use for it. Also, given that[/color]
the language has[color=blue]
>been in use for a few years now and there hasn't been[/color]
any huge outcry over[color=blue]
>it, I would think that it serves as validation of their[/color]
decision. I'm not[color=blue]
>saying it is right or wrong, just that it is not there,[/color]
and no one is really[color=blue]
>complaining about it.
>
> What exactly are you looking to achieve?
>
>
>--
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard. caspershouse.co m
>
>"Jesper" <anonymous@disc ussions.microso ft.com> wrote in[/color]
message[color=blue]
>news:0ca801c3d b72$be5df850$a3 01280a@phx.gbl. ..[color=green]
>> Do you know why this functionality (friend)is discarded
>> in C#, is it to be implemented in another way?
>>[color=darkred]
>> >-----Original Message-----
>> >Jesper,
>> >
>> > The only way that the internal keyword is going to[/color]
>> help is if both[color=darkred]
>> >classes are defined in the same assembly. If they[/color][/color][/color]
are,[color=blue][color=green]
>> then internal fields[color=darkred]
>> >are able to be seen by any of the classes in the same[/color]
>> assembly. The only[color=darkred]
>> >other option you have is protected, which forces you[/color][/color][/color]
to[color=blue][color=green]
>> derive from a base[color=darkred]
>> >class to see protected members.
>> >
>> > Hope this helps.
>> >
>> >
>> >--
>> > - Nicholas Paldino [.NET/C# MVP]
>> > - mvp@spam.guard. caspershouse.co m
>> >
>> >
>> >"Jesper" <anonymous@disc ussions.microso ft.com> wrote[/color][/color][/color]
in[color=blue][color=green]
>> message[color=darkred]
>> >news:045b01c3d b70$1e5c9570$a0 01280a@phx.gbl. ..
>> >> I need to grant a class access to protected fields[/color][/color][/color]
of[color=blue][color=green][color=darkred]
>> >> another class in the way its possible in C++ with[/color][/color][/color]
the[color=blue][color=green][color=darkred]
>> >> friend keyword. However I would like to keep the[/color][/color][/color]
class[color=blue][color=green][color=darkred]
>> >> protected towards other class within the same
>> >> program/assembly. The two classes are not 'related'
>> >> (inherited).
>> >>
>> >> How can I do this. I cant see how the keyword[/color][/color][/color]
Internal[color=blue][color=green][color=darkred]
>> >> can be used for this purpose.
>> >>
>> >> best regards Jesper.
>> >>
>> >
>> >
>> >.
>> >[/color][/color]
>
>
>.
>[/color]

Re: Internal vs friend (C++)

Hi Nicholas,[color=blue]
> Also, given that the language has
> been in use for a few years now and there hasn't been any huge outcry over
> it, I would think that it serves as validation of their decision.[/color]

I disagree with you here. Enough questions about *friend* or releated has
been asked it this news group. Thus, I believe that the absence of this
functionality is more like flaw.

Look at this for example.

Lots of objects are exported via properties of another object (owner) if we
want the owner to be notified for changes that happen in the exported
objects we have couple of choices:

1. The owner can hook up bunch of events which can be very annoying and can
polute the code with a lot of EventArgs classes and delegates. What if the
owner wants to return back some result. Because of the multicast nature of
the events returning value via events could be error prone unless special
precautions are taken which is another exces of code.

2. The owner can provide public or internal functions for those classes to
send notifications about thier state changes. Which polutes the owner with
methods documented or named in a manner to give the hint that they are for
internal use.

3. Declare the class internally in the owner class. Which doesn't work in
all casses and especially now when the classes cannot be spread across files
makes the owner-class file big and hard to read and maintain (at least it is
good that we have #region directive which is nice handled by the IDE).

It would be so easy if we had c++-friend-like functionality. Yes, I know
one may argue that *friend* breaks encapsulation of the objects but it can
be vary useful and can help to write more clear and maintainable code.

I agree that *internal* declared methods and properties kind of solves the
problem. Classes or methods has to be declared as *friend* inside the owner
class which means that the classes has to be well known to the owner at
compile type. Once compiled no new friends can be added. Which in turn means
that the owner and its friends more like comes from the same assembly.
However *internals* are visible to all classes in the assembly, so we cannot
be sure that a team-mate won't decide to take the short cut and call those
methos.

Unfortunately, it is not enough the c# team to add the *friend*
functionality it has to be supported by the CLR as well. Otherwise it won't
do.

B\rgds
100[color=blue]
>
> --
> - Nicholas Paldino [.NET/C# MVP]
> - mvp@spam.guard. caspershouse.co m
>
> "Jesper" <anonymous@disc ussions.microso ft.com> wrote in message
> news:0ca801c3db 72$be5df850$a30 1280a@phx.gbl.. .[color=green]
> > Do you know why this functionality (friend)is discarded
> > in C#, is it to be implemented in another way?
> >[color=darkred]
> > >-----Original Message-----
> > >Jesper,
> > >
> > > The only way that the internal keyword is going to[/color]
> > help is if both[color=darkred]
> > >classes are defined in the same assembly. If they are,[/color]
> > then internal fields[color=darkred]
> > >are able to be seen by any of the classes in the same[/color]
> > assembly. The only[color=darkred]
> > >other option you have is protected, which forces you to[/color]
> > derive from a base[color=darkred]
> > >class to see protected members.
> > >
> > > Hope this helps.
> > >
> > >
> > >--
> > > - Nicholas Paldino [.NET/C# MVP]
> > > - mvp@spam.guard. caspershouse.co m
> > >
> > >
> > >"Jesper" <anonymous@disc ussions.microso ft.com> wrote in[/color]
> > message[color=darkred]
> > >news:045b01c3d b70$1e5c9570$a0 01280a@phx.gbl. ..
> > >> I need to grant a class access to protected fields of
> > >> another class in the way its possible in C++ with the
> > >> friend keyword. However I would like to keep the class
> > >> protected towards other class within the same
> > >> program/assembly. The two classes are not 'related'
> > >> (inherited).
> > >>
> > >> How can I do this. I cant see how the keyword Internal
> > >> can be used for this purpose.
> > >>
> > >> best regards Jesper.
> > >>
> > >
> > >
> > >.
> > >[/color][/color]
>
>[/color]

Re: Internal vs friend (C++)

Meaning no disrespect, but I've seen very few cases of a "friend" design
that couldn't be done better in another manner, one that maintains strict
encapsulation.

In your example, Class2 needs to access internals of Class1. However,
Class3 doesn't and you want to hide the internals from Class3. Then it's
not really an "internal" value, is it?

Take a few moments and look at the design. Review the patterns in the GoF
book and look for a different approach, one that doesn't use "friend".

Honestly, there are dozens of very well described patterns in OO development
(GoF, Fowler, and many others). I don't recall ANY that require this
construct. (I may be wrong in that. My memory is not so perfect as to
recall the details of every single published pattern).

I intend no insult or offense. I simply suggest that your design may be
better off if you refactored it.
--- Nick

"Jesper" <anonymous@disc ussions.microso ft.com> wrote in message
news:0b1101c3db 78$caf9c1b0$a40 1280a@phx.gbl.. .[color=blue]
> Something like this, where I assert that an object is of
> a certain type in order to get access to a member of the
> class. Class2 cannot be inherited from Class1.
>
> class Class1
> {
> protected int i;
>
> Set_I(int i,object obj)
> {
> if (obj is Class2)
> {
> this.i = i;
> }
> }
> }
>
> If Class2 is a friend of Class1, I would not need to
> write a setter. Moreover I would get errors at compile
> time if I try to access the class from a class that is
> not a friend.
>
> by the way, thanks for answering
> brgds Jesper.
>
>[color=green]
> >-----Original Message-----
> >Jesper,
> >
> > It was never discarded. C# is not meant to be an[/color]
> extension or a[color=green]
> >variation on C++. It is a new language, and this[/color]
> functionality is simply[color=green]
> >just not there.
> >
> > As for why it is not there, I imagine that the[/color]
> original language[color=green]
> >designers didn't see much use for it. Also, given that[/color]
> the language has[color=green]
> >been in use for a few years now and there hasn't been[/color]
> any huge outcry over[color=green]
> >it, I would think that it serves as validation of their[/color]
> decision. I'm not[color=green]
> >saying it is right or wrong, just that it is not there,[/color]
> and no one is really[color=green]
> >complaining about it.
> >
> > What exactly are you looking to achieve?
> >
> >
> >--
> > - Nicholas Paldino [.NET/C# MVP]
> > - mvp@spam.guard. caspershouse.co m
> >
> >"Jesper" <anonymous@disc ussions.microso ft.com> wrote in[/color]
> message[color=green]
> >news:0ca801c3d b72$be5df850$a3 01280a@phx.gbl. ..[color=darkred]
> >> Do you know why this functionality (friend)is discarded
> >> in C#, is it to be implemented in another way?
> >>
> >> >-----Original Message-----
> >> >Jesper,
> >> >
> >> > The only way that the internal keyword is going to
> >> help is if both
> >> >classes are defined in the same assembly. If they[/color][/color]
> are,[color=green][color=darkred]
> >> then internal fields
> >> >are able to be seen by any of the classes in the same
> >> assembly. The only
> >> >other option you have is protected, which forces you[/color][/color]
> to[color=green][color=darkred]
> >> derive from a base
> >> >class to see protected members.
> >> >
> >> > Hope this helps.
> >> >
> >> >
> >> >--
> >> > - Nicholas Paldino [.NET/C# MVP]
> >> > - mvp@spam.guard. caspershouse.co m
> >> >
> >> >
> >> >"Jesper" <anonymous@disc ussions.microso ft.com> wrote[/color][/color]
> in[color=green][color=darkred]
> >> message
> >> >news:045b01c3d b70$1e5c9570$a0 01280a@phx.gbl. ..
> >> >> I need to grant a class access to protected fields[/color][/color]
> of[color=green][color=darkred]
> >> >> another class in the way its possible in C++ with[/color][/color]
> the[color=green][color=darkred]
> >> >> friend keyword. However I would like to keep the[/color][/color]
> class[color=green][color=darkred]
> >> >> protected towards other class within the same
> >> >> program/assembly. The two classes are not 'related'
> >> >> (inherited).
> >> >>
> >> >> How can I do this. I cant see how the keyword[/color][/color]
> Internal[color=green][color=darkred]
> >> >> can be used for this purpose.
> >> >>
> >> >> best regards Jesper.
> >> >>
> >> >
> >> >
> >> >.
> >> >[/color]
> >
> >
> >.
> >[/color][/color]

Re: Internal vs friend (C++)

Hi Nick, Thanks your kind reply and advise, I'll look into GoF etc
Best regards Jesper.