Internal vs friend (C++)

  • Thread starter Thread starter Jesper
  • Start date Start date
J

Jesper

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.
 
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.
 
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 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]
- (e-mail address removed)


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.
Click to expand...


.
Click to expand...
 
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]
- (e-mail address removed)

Jesper said:
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 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]
- (e-mail address removed)


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.
Click to expand...


.
Click to expand...
Click to expand...
 
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.

-----Original Message-----
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]
- (e-mail address removed)

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
Click to expand...
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
Click to expand...
to
derive from a base
class to see protected members.

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)


"Jesper" <[email protected]> wrote
Click to expand...
in
message
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.



.
Click to expand...
Click to expand...


.
Click to expand...
 
Hi Nicholas,
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.
Click to expand...

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
--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Jesper said:
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 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]
- (e-mail address removed)


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.



.
Click to expand...
Click to expand...
Click to expand...
 
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 said:
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.

-----Original Message-----
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]
- (e-mail address removed)

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 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]
- (e-mail address removed)


message
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.



.
Click to expand...


.
Click to expand...
Click to expand...
 
Back
Top