Friend modifier

  • Thread starter Thread starter Søren M. Olesen
  • Start date Start date
S

Søren M. Olesen

Hi

To my knowledge, when you in C++ use the friend keyword, then you also
specify which classes you consider to be friends...Ie. a named friend can
call protected/private methods in the class.....

Is there a way to do the same i VB.NET ?? It seem like if a method is
declared Protected Friend, then all classes in the same project can call the
method (rather unusefull, I think), not only named friends....

TIA

Søren
 
Søren M. Olesen said:
To my knowledge, when you in C++ use the friend keyword, then you also
specify which classes you consider to be friends...Ie. a named friend can
call protected/private methods in the class.....

Is there a way to do the same i VB.NET ?? It seem like if a method is
declared Protected Friend, then all classes in the same project can call the
method (rather unusefull, I think), not only named friends....

No, .NET doesn't have this concept yet, although it may well do when
Whidbey is released (in some form or other - I don't think it's been
finalized yet).

I disagree about the idea of all classes within the assembly being able
to access something being useless though - I find it very useful.
 
I disagree about the idea of all classes within the assembly being able
to access something being useless though - I find it very useful.

Yeah, but then you could almost just declare them public....You could achive
the same with the C++ friend... you'd just had to type a little more.....

Regards,

Søren
 
Søren M. Olesen said:
Yeah, but then you could almost just declare them public...

Not if you didn't want it exposed to the rest of the world. There's a
big difference between "code within my project" and "anyone accessing
my library".
You could achive
the same with the C++ friend... you'd just had to type a little more.....

Consider a class which is widely used within a project, but you don't
want to expose to the outside world. That's *perfect* for the C#
internal modifier, but would require loads of friend statements in C++
(I believe).

What would be additionally handy (I believe) would be access within a
namespace (either also restricted by assembly or not). There are times
it's useful to have a class accessible within the rest of a namespace,
but not elsewhere.

I find these kinds of situations crop up more often than the situation
where just one class needs to know about another one. (Or rather, the
latter is usually easily solvable with a nested class.)
 
Guess there's a need for both....Right now I'd like to have the C++ style to
limit access to child classes and named friend classes....

Regards,

Søren



Søren M. Olesen said:
Yeah, but then you could almost just declare them public...

Not if you didn't want it exposed to the rest of the world. There's a
big difference between "code within my project" and "anyone accessing
my library".
You could achive
the same with the C++ friend... you'd just had to type a little more.....

Consider a class which is widely used within a project, but you don't
want to expose to the outside world. That's *perfect* for the C#
internal modifier, but would require loads of friend statements in C++
(I believe).

What would be additionally handy (I believe) would be access within a
namespace (either also restricted by assembly or not). There are times
it's useful to have a class accessible within the rest of a namespace,
but not elsewhere.

I find these kinds of situations crop up more often than the situation
where just one class needs to know about another one. (Or rather, the
latter is usually easily solvable with a nested class.)
 
There is NO GOOD REASON for friends. It should be taken out and shot, buried
in the parking lot. The concept of friends indicates poorly designed
infrastructure. And I have yet to see a valid example where it is needed. I
cannot imagine why it would be in the framework.

Yes, i have issues with friends.
 
Back
Top