why C# doesn't support "friend" relationship?

  • Thread starter Thread starter Zeng
  • Start date Start date
Z

Zeng

It's so messy w/o the "friend" relationship. Does anyone know why it was
not supported in C#. It's almost about as bad as it doesn't support the
inheritance hierarchy and method reference (calling tree) browsing that is
supported in C++. I don't know how some could write a large scale
object-oriented application w/o those. If you have overcome these
limitations in C#, please share your thoughts and ideas. Thanks!
 
1) Friend is not so great in and of itself, but that aside
you have "internal" and "protected internal"...

2) View/Class View from main menu and you can browse to
your hearts content...
 
Zeng said:
It's so messy w/o the "friend" relationship. Does anyone know why it was
not supported in C#. It's almost about as bad as it doesn't support the
inheritance hierarchy and method reference (calling tree) browsing that is
supported in C++.

Hang on - "browsing" sounds like it's something to do with the IDE, not
with the language itself. Or have I misunderstood?
I don't know how some could write a large scale
object-oriented application w/o those. If you have overcome these
limitations in C#, please share your thoughts and ideas. Thanks!

Having not done much C++, I can't say there have been many times where
I've thought, "Ah, what I really need here is friend access." Internal
is usually fine - especially if you don't mind having a separate
assembly for each subsystem in your app. Occasionally I've felt it
would be nice to have a namespace access level, like package access in
Java (although possibly without its implicit protected access), but
that's been pretty rare.

I can't say it's really been a barrier to writing C#.
 
Hi Zeng,

Even though, I miss *friend* once in a while I dont't thing that is a big
loss.
When you declare a type as inner of other type. The former is friend of the
outer and has unlimited access to all memebers. Doesn't work the other way
arround, though. I mostly used *friend* in c++ when I was overloading the
operators with global functions. However, it is not the case with .NET.
In addition you have *internal* access modifier.
Actually I believe that *friend* methods could make the big mess if it is
not used sparingly.

About the second part of the question. Yes, you have all this in the *class
viewer*. This is IDE feature and has nothing to do with C#, C++ or any other
language, though.


HTH
B\rgds
100
 
- Virtual protected internal methods trigger compiler warnings that we can't
turn it off individually.
- Class Resident has Police as a friend (in C++), if you put Police to the
same assembly then it won't be able to be in the assemply with other classes
like PoliceOffice
- If i'm going to modify a core code (let's say a method), how do I use
View/ClassView to find out quickly which code will be impacted by my
changes? In C++ IDE, I would have to see who reference the method, who
inherits the class, and most of the times who references it's overriden
methods, and trace it along the inheritence hierarchy and sideway to other
related methods. Right now, in C#, I would have to do a "find in files"
operation for each single mouse click that I used to do with C++ IDE and
still don't have the same overall relationship picture.
-View/Class View doesn't tell who inherit your class, it only tell you who
your class inherits.
 
Because we only have 1 IDE (as least that I know of) available for C#, so
practically the IDE limitation has everything to do with C#, and woud
someone dare to develop their own IDE for C# to compete with MS? Or maybe MS
will write another IDE for C++ users?
 
Zeng,
Have you looked into Refactoring and some of the C# Refactoring tools?

http://www.refactoring.com

See the .NET section for C# tools:
http://www.refactoring.com/tools.html

Refactoring is a technique to restructure code in a disciplined way.

What I have been doing in VB.NET is applying the Obsolete Attribute to the
element (method, class, field) that I intend on modifying, then I get a list
of warnings every place that element is used. I then proceed with the
Refactoring as normal.

Hope this helps
Jay
 
I don't use it either. Just wanted to show that there were alternatives.
And that MS isn't stopping those that have the desire to try and outdo
them...
 
What about features lacking like serial ports and other kinda things that we
have to hook into CraptiveX components to do.
 
Sure they are "related". Furthermore, if the VB development team's recent
presentation of new Whidbey features at VSLive! is any indication, the line
between language vs. IDE vs. framework features is a little blurry.

So, how about it - any word on implementing serial communications (in the
framework or otherwise)? For us folks in the Manufacturing sector that's
one of the biggest showstopping hurdles .NET has to overcome.
 
Daniel Billingsley said:
Sure they are "related".

No they aren't. Adding the 'friend' relation has to do with C# because it
will introduce new keywords in the language.
Adding some serial communication classes to the framework has nothing to do
with C# or VB.NET -- it has to do with the base class library.
So, how about it - any word on implementing serial communications (in the
framework or otherwise)?

Use one of the various free and open source implementations. Here are some:
http://msdn.microsoft.com/msdnmag/issues/02/10/NETSerialComm/default.aspx
http://www.codeworks.it/net/VBNetRs232.htm

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl
 
Yes it has to do with the "framework" not the language.

Still, its part of the problem of adoption of C# and the .NET framework in
REAL WORLD sectors, not this fantasy bullshit web services crapola.

We dont care for that shit, we make machines that make machines and save
lives, web services will not be anywhere in the medical applications, and
definately not in the automation sector.

Microsoft lost the plot when it came to a platform for developement.
 
Because we only have 1 IDE (as least that I know of) available for C#,

1) MS Visual Studio.NET
2) Borland C#BUilder
3) SharpDevelop
4) Any text editor + the command-line compiler

you got *AT LEAST* four optoins !

Marc
 
Adding classes to the framework has "NOTHING TO DO WITH C#" - what planet
are you on man?!
 
Back
Top