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

  • Thread starter Thread starter Zeng
  • Start date Start date
Daniel Billingsley said:
Adding classes to the framework has "NOTHING TO DO WITH C#" - what planet
are you on man?!
Click to expand...

It has nothing to do with the "C# the language" - but it obviously has
a lot to do with where/how C# can be used. The precise specification of
C# is unlikely to change one iota just to accomodate serial
communications.

Put it this way - I certainly wouldn't expect to see it on a "new C#
features" list, because it would never *be* a C# feature, it would be a
framework feature.
 
I only ever used the friend feature on operators like you mention.
Personally, I think it doesn't have much place in "proper OO". If you really
need to hide something away, yet let people have access to it, and internal
isn't good enough, you can hide things with explicit interface
implementation.

I think once you decide that you want something private to be accessible
outside, you're really talking about something that's public, and having
your team's coders have the discipline not to fiddle with it if they don't
know what they're doing. If it's really that bad to fiddle with the feature,
you can hide it behind an interface. Personally, I think that using explicit
interface implementation to hide things is a disgusting misuse of
interfaces, but it hurts encapsulation less than friends :P

Just remember... you can pick your friends, you can pick your nose. But you
can't pick your friend's nose.

Niall
 
We're considering adding some friend support in Whidbey.


please don't do that! isn't there a better solution?
 
Zeng said:
- Virtual protected internal methods trigger compiler warnings that we can't
turn it off individually.
Click to expand...

In the base class, create an internal method that forwards to a
private virtual method:

internal class B
{
internal void method()
{
v_method();
}

private virtual void v_method()
{
// default implementation
}
}

internal class D : B
{
private virtual void v_method()
{
...
}
}
 
Eric Gunnerson said:
We're considering adding some friend support in Whidbey.
Click to expand...

Of all the things that C# needs, friend is not one of them. Support
for
real generic programming, with partial specialization, non-type
arguments, and implicit function instantiation would be useful.
Support for RAII that does not require 20 lines of
Dispose-GC.SuppressFinalization boilerplate would be nice. Some
support for functional programming would be very useful. Some
general-purpose container algorithms ala the C++ STL would help a lot.
Moving from C++ to C#, I feel like my nice drawerful of tools was
taken away and I was handed a box of crayons and a pair of plastic
blunt-tip scissors.
 
gratulations: one of the most interesting post here.
Of all the things that C# needs, friend is not one of them. Support
for
real generic programming, with partial specialization, non-type
arguments, and implicit function instantiation would be useful.
Support for RAII that does not require 20 lines of
Dispose-GC.SuppressFinalization boilerplate would be nice.
Click to expand...

arguments that have no type? what is RAII? partial specialisation? function
instantiation?
i would be extremely pleased if sombody could explain me what you are
talking about. it sounds very interesting.
Some support for functional programming would be very useful. Some
general-purpose container algorithms ala the C++ STL would help a lot.
Moving from C++ to C#, I feel like my nice drawerful of tools was
taken away and I was handed a box of crayons and a pair of plastic
blunt-tip scissors.
Click to expand...

hehe thats right :)
 
Kevin Cline said:
"Eric Gunnerson [MS]" <[email protected]> wrote in message
We're considering adding some friend support in Whidbey.
Click to expand...

Of all the things that C# needs, friend is not one of them. Support
Click to expand...
Quite agreed. It was annoying in C++ and would just bug me in C#. To easy to
abuse and too many people who would abuse it, its not worth the maybe 1 in
every 30,000 cases where it would be of any value whatsoever.
for
real generic programming, with partial specialization, non-type
arguments, and implicit function instantiation would be useful.
Support for RAII that does not require 20 lines of
Dispose-GC.SuppressFinalization boilerplate would be nice. Some
support for functional programming would be very useful. Some
general-purpose container algorithms ala the C++ STL would help a lot.
Moving from C++ to C#, I feel like my nice drawerful of tools was
taken away and I was handed a box of crayons and a pair of plastic
blunt-tip scissors.
Click to expand...

But it also took away that running chainsaw you were always risking sitting
on. One thing I really worry about is the formation of an STL equivilent.
Templates in C++ were not pleasent and often drove me crazy. I don't know
how many times a template failed to work for whatever reason, issuing a
massive number of compile time errors that I couldn't hope to handle. It
would, eventually, cause me to waste a huge amount of time trying to figure
out why a) If wizards couldn't pump out correct, predesigned code, how the
hell was I supposed to, and b) Why, exactly, did this class need 80000 lines
of code to print to the console.
You lost some tools, yes, but you also gained a much cleaner universe to
work in. Remember that when it comes down to it, clean, simple, easy code
should ALWAYS rule in C#. Anything, like full on templates, that begins to
complicate code and make it a chore to use will destroy the language. C#
does not need to be C++, should not be C++, and if it ever becomes C++ I'm
going to Java(or maybe Eiffel) and I doubt I'd be the only one.
I would also suspect that you would also find alot of the tools you feel are
missing if you actually give up C++ and think in C#. The languages are
different and you should never work in one in the way you would work in the
other. If you feel you need the STL, you are quite welcome to use C++, it
exists in the managed world too.
Now, that my rant is over, some of hte features you mentioned would be nice.
Partial specialization, for example. However, RAII shouldn't be used in C#,
other patterns, IDisposable for example, exist instead.

Functional programming features would be nice, at times, but I do not think
it is a nessecity. I do wish however that instead of iterators, we were
getting full-fledged coroutines. Best I can tell the yield keyword will
exist only in interator code.
 
Friends break the OOP agreement of data encapsulation. It was rightly
frowned upon. disregarded quartered and killed in .NET - (in fine print: it
was brought back to life as assembly internal)

what are you trying to do that you need a friend class anyway? I've yet to
come across a design that absolutely needed friendship. Correct me somebody.
 
I think you are seriously confusing IDE requirements with OOP
implementation. If you want to find relationships at designtime, there are
myriad of tools to point out the relationships. You do not compromise OOP
integrity to make life convenient for the user looking for the convenience
of object relationships. IMO
 
Gowd that is such a bad idea. that is such a bad idea. i don't think i will
sleep tonight because of that bad idea.

Educate us Eric Gu, tell us why this is being considered
 
My rant. They need to fire the guys who developed C# because now they seem
to want to mess it up by tinkering with a good thing.

Daniel O'Connell said:
Kevin Cline said:
"Eric Gunnerson [MS]" <[email protected]> wrote in message
We're considering adding some friend support in Whidbey.
Click to expand...

Of all the things that C# needs, friend is not one of them. Support
Click to expand...
Quite agreed. It was annoying in C++ and would just bug me in C#. To easy to
abuse and too many people who would abuse it, its not worth the maybe 1 in
every 30,000 cases where it would be of any value whatsoever.
for
real generic programming, with partial specialization, non-type
arguments, and implicit function instantiation would be useful.
Support for RAII that does not require 20 lines of
Dispose-GC.SuppressFinalization boilerplate would be nice. Some
support for functional programming would be very useful. Some
general-purpose container algorithms ala the C++ STL would help a lot.
Moving from C++ to C#, I feel like my nice drawerful of tools was
taken away and I was handed a box of crayons and a pair of plastic
blunt-tip scissors.
Click to expand...

But it also took away that running chainsaw you were always risking sitting
on. One thing I really worry about is the formation of an STL equivilent.
Templates in C++ were not pleasent and often drove me crazy. I don't know
how many times a template failed to work for whatever reason, issuing a
massive number of compile time errors that I couldn't hope to handle. It
would, eventually, cause me to waste a huge amount of time trying to figure
out why a) If wizards couldn't pump out correct, predesigned code, how the
hell was I supposed to, and b) Why, exactly, did this class need 80000 lines
of code to print to the console.
You lost some tools, yes, but you also gained a much cleaner universe to
work in. Remember that when it comes down to it, clean, simple, easy code
should ALWAYS rule in C#. Anything, like full on templates, that begins to
complicate code and make it a chore to use will destroy the language. C#
does not need to be C++, should not be C++, and if it ever becomes C++ I'm
going to Java(or maybe Eiffel) and I doubt I'd be the only one.
I would also suspect that you would also find alot of the tools you feel are
missing if you actually give up C++ and think in C#. The languages are
different and you should never work in one in the way you would work in the
other. If you feel you need the STL, you are quite welcome to use C++, it
exists in the managed world too.
Now, that my rant is over, some of hte features you mentioned would be nice.
Partial specialization, for example. However, RAII shouldn't be used in C#,
other patterns, IDisposable for example, exist instead.

Functional programming features would be nice, at times, but I do not think
it is a nessecity. I do wish however that instead of iterators, we were
getting full-fledged coroutines. Best I can tell the yield keyword will
exist only in interator code.
Click to expand...
 
How about foe support?

Sure - but then you need some reliable friend/foe identification
system! ;-)

Marc

================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
We're considering adding some friend support in Whidbey.
please don't do that! isn't there a better solution?
Click to expand...

I agree - "friend" is like an OO version of GOTO - considered harmful
and ought to be avoided.

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
That's like saying gasoline or highways have nothing to do with automobiles.
Asinine. His statement was "nothing to do with" - that means not related in
any way. Equally absurd.

I'm not trying just to be argumentative - my main point is that the line
between language, the VS IDE, and the framework gets a bit blurry, and that
blur is even propagated by Microsoft.

I understand the difference between a framework feature and a C# language
feature perfectly well. My point is that, for example, adding a framework
feature that eliminates the need to even discuss the workarounds using the
C# language itself has EVERYTHING to do with the C# language.
 
Daniel Billingsley said:
That's like saying gasoline or highways have nothing to do with automobiles.
Click to expand...

I don't actually think that's a good analogy, but there we go.
Asinine. His statement was "nothing to do with" - that means not related in
any way. Equally absurd.

I'm not trying just to be argumentative - my main point is that the line
between language, the VS IDE, and the framework gets a bit blurry, and that
blur is even propagated by Microsoft.
Click to expand...

I don't believe it *is* that blurry, actually - certainly not in this
case. The language requires certain things of the framework, but
anything that isn't directly related to the language is pretty
irrelevant as far as the language itself is concerned. It makes no
difference to the language whether or not there's a
System.Collections.Specialized.NameValueCollection class, for instance
- whereas it *does* matter to the language whether or not there's an
AttributeUsageAttribute class, because that's directly referenced
within the specification itself.
I understand the difference between a framework feature and a C# language
feature perfectly well. My point is that, for example, adding a framework
feature that eliminates the need to even discuss the workarounds using the
C# language itself has EVERYTHING to do with the C# language.
Click to expand...

I'm sure there are some framework features which would be grey areas -
but the addition of serial port access is certainly not such a feature.
The lack of access to serial ports is in no way a limitation of C#-the-
language. It's a limitation you run into when *using* C#-the-language,
but that really is a different matter. It's not something you'd put
before the C# language specification team, it's something you'd put
before the framework team.
 
Now, that my rant is over, some of hte features you mentioned would be
nice.
Partial specialization, for example. However, RAII shouldn't be used in C#,
other patterns, IDisposable for example, exist instead.

Functional programming features would be nice, at times, but I do not think
it is a nessecity. I do wish however that instead of iterators, we were
getting full-fledged coroutines. Best I can tell the yield keyword will
exist only in interator code.
Click to expand...


what is Partial specialization and RAII?
 
Jon Skeet said:
I don't actually think that's a good analogy, but there we go.
Click to expand...

It's a perfect analogy, considering the next point below. Automobiles can
be used without gasoline, but in statistically all cases gasoline has a
direct and close relationship with the use of the automobile.
The lack of access to serial ports is in no way a limitation of C#-the-
language. It's a limitation you run into when *using* C#-the-language,
but that really is a different matter. It's not something you'd put
before the C# language specification team, it's something you'd put
before the framework team.
Click to expand...

Depends on how you define "limitation". It is certainly something the
language doesn't do, but could do. For obvious reasons this is best solved
with a framework feature, but it doesn't have to be. Like as in the
gasoline-automobile analogy, we see then that the framework design even
directly affects the language design.

Anyway, based on the statement above if you're still taking the position
that framework discussion is not appropriate in this NG, you find yourself
saying that a C# NG is not about "using" the language, and I find that
silly. You write your first C# "hello world" console application and it's
more framework than C#.

Further the propagation of the blur I'm talking about is that it would not
be the least bit surprising to hear the C# team talking about that new
framework feature when showing off new Whidbey (or whatever version)
features. You may find that hard to believe, but I'm telling you me and
several hundred other people watched the VB team do exactly that (not
regarding serial IO of course) at VSLive! Orlando last month. Why?
Because, of course, they know full well that "using" the language is
precisely the purpose of its creation. Microsoft didn't create C# so it
could have a specification, they did it so people would "use" it. So, I
think Microsoft would find it rather amusing (or perhaps annoying) that you
suggest their C# NG is only about discussing the specification features and
not about creating algorithms or software with it (which undoubtedly
intimately involves the framework for all practical purposes). (Well ok, it
wasn't you, but you'll recall the other poster suggested that this NG
should not even discuss algorithms written in C#.)

Now, just so you understand I'm not arguing for its own sake, I understand
there is a point where a discussion is not really appropriate here. Someone
starts asking about querying machine information and that turns into a
discussion of why Microsoft calls XP a version of "NT" or why you can't
retrieve the date the OS was installed - that's clearly moved outside the
scope of this NG even though it is indirectly about using C# to call
framework classes. Of course, everyone will have their own opinion as to
when the proverbial "line" is crossed. I'm saying simply that making that
line at the 70 or so C# keywords just doesn't make any sense.

And of course, the bigger question in these kinds of discussions is whether
or not topics about the definition of on-topic is on-topic. Peace, bro. :)
 
Daniel Billingsley said:
It's a perfect analogy, considering the next point below. Automobiles can
be used without gasoline, but in statistically all cases gasoline has a
direct and close relationship with the use of the automobile.
Click to expand...

Well, in statistically most, certainly. There are plenty of uses for
gasoline outside cars (petrol mowers, for instance, but there we go).
Even if it appears to fit the words, I still don't believe it's an
appropriate analogy. We're not going to agree here - that's just life.
Depends on how you define "limitation". It is certainly something the
language doesn't do, but could do. For obvious reasons this is best solved
with a framework feature, but it doesn't have to be. Like as in the
gasoline-automobile analogy, we see then that the framework design even
directly affects the language design.
Click to expand...

I would certainly *hope* that any framework library for accessing
serial ports didn't require any extra language features. If they did,
it would be a shockingly badly designed library.
Anyway, based on the statement above if you're still taking the position
that framework discussion is not appropriate in this NG, you find yourself
saying that a C# NG is not about "using" the language, and I find that
silly. You write your first C# "hello world" console application and it's
more framework than C#.
Click to expand...

I don't know where you got the idea that I'm "still" taking the
position that framework discussion is not appropriate in this NG - I
don't believe I've taken that position yet. However, I do believe that
posts which have more to do with the use of the framework than specific
C# points are more appropriate in the microsoft.public.dotnet.framework
group. I'm never going to try to "police" that, however, because I know
it's a pointless struggle.
Further the propagation of the blur I'm talking about is that it would not
be the least bit surprising to hear the C# team talking about that new
framework feature when showing off new Whidbey (or whatever version)
features.
Click to expand...

They may be talking about them, but that doesn't mean they needed to be
there for design or implementation. Of course, CLR features such as
generics *do* need to be supported by the language, and those are the
things more likely to be talked about. For instance, looking at the
"future C# language features" page: http://tinyurl.com/848u
there's no talk about framework changes which aren't also reflected in
the language specification.
You may find that hard to believe, but I'm telling you me and
several hundred other people watched the VB team do exactly that (not
regarding serial IO of course) at VSLive! Orlando last month.
Click to expand...

I don't find it hard to believe - but that doesn't mean that there
isn't or can't be a clear dividing line between language and framework.
The fact that language team members choose to highlight benefits
provided by those outside the team doesn't alter that, IMO.
Why?
Because, of course, they know full well that "using" the language is
precisely the purpose of its creation. Microsoft didn't create C# so it
could have a specification, they did it so people would "use" it. So, I
think Microsoft would find it rather amusing (or perhaps annoying) that you
suggest their C# NG is only about discussing the specification features and
not about creating algorithms or software with it (which undoubtedly
intimately involves the framework for all practical purposes). (Well ok, it
wasn't you, but you'll recall the other poster suggested that this NG
should not even discuss algorithms written in C#.)
Click to expand...

Indeed, and I wouldn't suggest that - although I would *prefer*
questions here to at least have *something* specific to the C# language
rather than *solely* being framework related. As I said before, it's
not going to happen, and I've accepted that - but that doesn't mean
it's necessarily the best way things can be.

<snip>
 
Well Jon, I think we are in 100% agreement on the core issue. My "beef"
with you started when you took a position in defense of the guy who was
posting such radical nonsense as algorithm discussions being outside the
scope of this NG.

Jon Skeet said:
Well, in statistically most, certainly. There are plenty of uses for
gasoline outside cars (petrol mowers, for instance, but there we go).
Even if it appears to fit the words, I still don't believe it's an
appropriate analogy. We're not going to agree here - that's just life.
Click to expand...

But that's not the point. The question is whether it would be appropriate
to talk somewhat about gasoline when discussing automobiles, and the obvious
answer is yes. Oil refining techniques, no - which station has the purest
fuel and makes your Chevy run better, definitely. Yes gas has other
purposes, and the framework can be used by other languages - precisely why
the analogy fits so well.
I would certainly *hope* that any framework library for accessing
serial ports didn't require any extra language features. If they did,
it would be a shockingly badly designed library.
Click to expand...

I too would expect it wouldn't, but it certainly does affect whether or not
any new language features are required to solve the problem some other way,
just as the stringbuilder negated the need for similar functionality in the
language itself, although it certainly COULD have been added there (and been
very ugly).
I don't know where you got the idea that I'm "still" taking the
position that framework discussion is not appropriate in this NG - I
don't believe I've taken that position yet. However, I do believe that
posts which have more to do with the use of the framework than specific
C# points are more appropriate in the microsoft.public.dotnet.framework
group. I'm never going to try to "police" that, however, because I know
it's a pointless struggle.
Click to expand...

Like i said, we don't disagree. But what percentage of any application you
write is framework? My point is the majority of posts which starts off as
"how do i..." will be answered with discussion of some framework feature and
it could get real ugly if everyone just started responding with "ask in the
framework NG".
I don't find it hard to believe - but that doesn't mean that there
isn't or can't be a clear dividing line between language and framework.
The fact that language team members choose to highlight benefits
provided by those outside the team doesn't alter that, IMO.
Click to expand...

No, it doesn't blur the distinction at all, that's not my point... it
illustrates the blur in the definition of a discussion of one or the other.
Indeed, and I wouldn't suggest that - although I would *prefer*
questions here to at least have *something* specific to the C# language
rather than *solely* being framework related. As I said before, it's
not going to happen, and I've accepted that - but that doesn't mean
it's necessarily the best way things can be.
Click to expand...

Agreed. I would just say that many people asking the "how do I..."
questions don't understand the distinction nearly as well as you. It seems
very logical to ask how to access their database with their C# program in a
C# NG, but in reality it probably has 0% to do with C# per se. I'm saying
this not to you but for others that have been following this (because you've
explained it's not applicable to your MO here) - just keep in mind that
there is not really all that much to the language itself in the context of a
full-blown application, but not everyone understands that.
 
Back
Top