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

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.

"Willy Denoyette [MVP]" <wi*************@pandora.be> wrote in message
news:OS**************@TK2MSFTNGP10.phx.gbl...

These features are not related to the C# language.

Willy.
"Mr.Tickle" <Mr******@mrmen.com> wrote in message

news:uL**************@TK2MSFTNGP09.phx.gbl...

What about features lacking like serial ports and other kinda things that we have to hook into CraptiveX components to do.

Nov 15 '05 #16

These features are not related to the C# language.

Willy.
"Mr.Tickle" <Mr******@mrmen.com> wrote in message

news:uL**************@TK2MSFTNGP09.phx.gbl...

What about features lacking like serial ports and other kinda things that we have to hook into CraptiveX components to do.

Nov 15 '05 #17

Pieter Philippaerts

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message

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/is...m/default.aspx
http://www.codeworks.it/net/VBNetRs232.htm

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

Nov 15 '05 #18

Pieter Philippaerts

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message

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)?

Nov 15 '05 #19

Mr.Tickle

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.
"Pieter Philippaerts" <Pi****@nospam.mentalis.org> wrote in message
news:uq*************@tk2msftngp13.phx.gbl...

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
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/is...m/default.aspx
http://www.codeworks.it/net/VBNetRs232.htm

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

Nov 15 '05 #20

Mr.Tickle

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
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/is...m/default.aspx
http://www.codeworks.it/net/VBNetRs232.htm

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

Nov 15 '05 #21

>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

Nov 15 '05 #22

Nov 15 '05 #23

Adding classes to the framework has "NOTHING TO DO WITH C#" - what planet
are you on man?!
"Pieter Philippaerts" <Pi****@nospam.mentalis.org> wrote in message
news:uq*************@tk2msftngp13.phx.gbl...

"Daniel Billingsley" <db**********@NO.durcon.SPAAMM.com> wrote in message
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/is...m/default.aspx
http://www.codeworks.it/net/VBNetRs232.htm

Regards,
Pieter Philippaerts
Managed SSL/TLS: http://www.mentalis.org/go.php?sl

Nov 15 '05 #24

Jon Skeet [C# MVP]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

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

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #25

Niall

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

"100" <10*@100.com> wrote in message
news:ej**************@TK2MSFTNGP11.phx.gbl...

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
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!

Nov 15 '05 #26

codymanix

> We're considering adding some friend support in Whidbey.
please don't do that! isn't there a better solution?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 15 '05 #27

Thomas Eyde

How about foe support?

Nov 15 '05 #28

Kevin Cline

"Zeng" <zz*@nonospam.com> wrote in message news:<ut**************@TK2MSFTNGP09.phx.gbl>...

- Virtual protected internal methods trigger compiler warnings that we can't
turn it off individually.

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()
{
...
}
}

Nov 15 '05 #29

Kevin Cline

"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message news:<Os*************@TK2MSFTNGP12.phx.gbl>...

We're considering adding some friend support in Whidbey.

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.

Nov 15 '05 #30

codymanix

gratulations: one of the most interesting post here.

We're considering adding some friend support in Whidbey.
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.

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.

hehe thats right :)

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 15 '05 #31

Daniel O'Connell

"Kevin Cline" <kc******@hotmail.com> wrote in message
news:ba**************************@posting.google.c om...

"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message news:<Os*************@TK2MSFTNGP12.phx.gbl>...
We're considering adding some friend support in Whidbey.

Of all the things that C# needs, friend is not one of them. Support

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.

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.

Nov 15 '05 #32

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.

"Zeng" <zz*@nonospam.com> wrote in message
news:#g**************@tk2msftngp13.phx.gbl...

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!

Nov 15 '05 #33

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

"Zeng" <zz*@nonospam.com> wrote in message
news:ut**************@TK2MSFTNGP09.phx.gbl...

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

"Richard" <ri******@amgen.com> wrote in message
news:09****************************@phx.gbl...

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...
-----Original Message-----

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!

.

Nov 15 '05 #34

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
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message
news:Os*************@TK2MSFTNGP12.phx.gbl...

We're considering adding some friend support in Whidbey.

"Zeng" <zz*@nonospam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

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!

Nov 15 '05 #35

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" <onyxkirx@--NOSPAM--comcast.net> wrote in message
news:sF0hb.710359$Ho3.156800@sccrnsc03...

"Kevin Cline" <kc******@hotmail.com> wrote in message
news:ba**************************@posting.google.c om...
"Eric Gunnerson [MS]" <er****@online.microsoft.com> wrote in message news:<Os*************@TK2MSFTNGP12.phx.gbl>...
We're considering adding some friend support in Whidbey.

Of all the things that C# needs, friend is not one of them. Support

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

Nov 15 '05 #36

>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

Nov 15 '05 #37

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

please don't do that! isn't there a better solution?

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

Nov 15 '05 #38

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.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:
Adding classes to the framework has "NOTHING TO DO WITH C#" - what planet are you on man?!

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.

Nov 15 '05 #39

Jon Skeet [C# MVP]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

That's like saying gasoline or highways have nothing to do with automobiles.
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.
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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #40

codymanix

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

what is Partial specialization and RAII?

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk

Nov 15 '05 #41

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

I don't actually think that's a good analogy, but there we go.
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.

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. :)

Nov 15 '05 #42

Jon Skeet [C# MVP]

Daniel Billingsley <db**********@NO.durcon.SPAAMM.com> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
I don't actually think that's a good analogy, but there we go.
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.

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.

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.

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.

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#.
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.
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.
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#.)

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>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #43