Language inadequacies

[Darren Oakey]

Hi all,
I just thought I'd throw down what I think are the three biggest language
inadequacies of C#, hopefully so that people will jump on the bandwagon and
lobby MS to fix them! So - in order:

*** 1 - lack of const ***
I know this has been mentioned before, so I won't get into it, but really,
WHAT WERE THEY THINKING??? Personally, I'd actually like to go a little
further and invert the const logic - so all parameter declarations are const
unless otherwise specified. "changes" keyword? But seriously, we NEED a
const. I am literally going through and making a const interface of every
class, which I pass around most of the time to compensate. It doubles the
workload

*** 2 - templates ***
we need them, they are going to come, so why weren't they there from the
beginning???? The worst thing is, if you look at the MS research site, the
way they are trying to put them in _changes the framework_!! (so much for
all those people developing for other devices, like me!!) Now, lets
remember that C++ was just a preprocessor over C... Who's going to be the
first to make the C# template preprocessor that integrates with the IDE -
you'd make a fortune!

*** 3 - statics in interfaces ***
This is the one that incited this because I haven't seen a lot of people
talking about it, but it gets me almost every day. I was whinging about it
to a friend today, and he said he had exactly the same problem yesterday -
why isn't it more of a complaint?

Why the hell (mind my French) can't we put a static function in an
interface??? So often I come up with this! I'll give you just one example
of many :
Interface Move
{
Player Player {get;}
Piece Piece {get;}
BoardSpace Space {get;}
bool IsNullMove {get;}f
}

Fine - that's your Move interface.. but you want a s

 

[Darren Oakey]

oops... let me continue:

Why the hell (mind my French) can't we put a static function in an
interface??? So often I come up with this! I'll give you just one example
of many :
Interface Move
{
Player Player {get;}
Piece Piece {get;}
BoardSpace Space {get;}
bool IsNullMove {get;}
}

Fine - that's your Move interface.. but you want to return a special move
called NoMove - what you really want to do is create a single class, the
NoMove class, and add a static function to the Move interface
Interface Move
{
private class NoMove : Move
{
...
bool IsNullMove {get {return true;}}
}

public static Move NoMove {get {return new NoMove;}}
}
So that you can just use Move.NoMove - just like you would use GUID.NewGUID,
or any other static builder function. There is absolutely no technical
reason why an interface shouldn't allow it, so WHY? have MS put in this
artificial restriction??

anyway, that's my rant and rave, off my chest now
apart from that, great language! <grin>

 

[Rob Tillie]

Hey,

why the hell do you want the const keyword for params?
I've programmed in C++, but never used it. Why the heck should I.
I have never had a problem with it. Isn't it just because you're used to it
that u miss it?
I began with C++ already knowing Java, that's the reason why I never used
it.

Greetz,
-- Rob.

 

[Willie B. Hardigan]

one size doesn't fit all, judgement call.

 

[Rob Tillie]

Because if you don't the caller of your function must assume that it
will modify the parameter. If the caller needs the parameter to
retain it's original state he must make a deep copy of the value that
was to be the parameter and then pass the copy instead of the
original value. Having to do this is extra work and causes runtime
overhead.

Don't you have to declare a param as "out" in order for it to be changed on
the outside?

In C# const isn't available so you must guess whether a method
modifies a parameter. This is highly unsafe.

But when do you ever use it? You could change it around and say, a param is
never modified, unless it is declared as out.

I miss it because it makes my code safer, more self documenting and
less confusing to the developers that use it. const is not some
esoteric language feature used rarely, it's an integral part of good
C++ programming and taught by every beginners book worth a cent.

Well, I agree with you. But, I rather see it the other way around. A method
never alters a param unless it is declared as such. Otherwise you 're
getting an awfull lot of consts.

Don't try to program C++ with a java mindset, it's very bad idea.

I know. Same thing as trying to program VB when you know Java.
Anyway, I had to . Had to write some compilers and 3d environments in C++.
But it took quite a getting used to in the beginning.

Greetz,
-- Rob.

 

[Magnus Lidbom]

Hi all,
I just thought I'd throw down what I think are the three biggest language
inadequacies of C#, hopefully so that people will jump on the bandwagon and
lobby MS to fix them! So - in order:

*** 1 - lack of const ***
I know this has been mentioned before, so I won't get into it, but really,
WHAT WERE THEY THINKING???

<snip>
I agree 100%. const is simply a must have language feature IMO.
I'm as stumped as you are as to why this is not in the language.

*** 2 - templates ***
we need them, they are going to come, so why weren't they there from the
beginning???? The worst thing is, if you look at the MS research site, the
way they are trying to put them in _changes the framework_!! (so much for
all those people developing for other devices, like me!!) Now, lets
remember that C++ was just a preprocessor over C... Who's going to be the
first to make the C# template preprocessor that integrates with the IDE -
you'd make a fortune!

I'm haven't taken a close look at C# generics, but from what I've heard they
will provide only a small subset of the power of C++ templates. Apparently
this was a conscious choice between complexity and power. IMO it's a very
unfortunate decision. New uses for template metaprogramming are invented
all the time, and after reading books such as "Modern C++ Design" and
"C++ Templates the Complete Guide" I just can't see how you'd be willing to
sacrifice such power just to "keep it simple".

*** 3 - statics in interfaces ***
This is the one that incited this because I haven't seen a lot of people
talking about it, but it gets me almost every day. I was whinging about it
to a friend today, and he said he had exactly the same problem yesterday -
why isn't it more of a complaint?

Interface Move
{
private class NoMove : Move
{
...
bool IsNullMove {get {return true;}}
}

public static Move NoMove {get {return new NoMove;}}
}

I'm not so sure about this one, how will collisions when implementing
multiple interfaces be resolved?



<snip>

 

[Magnus Lidbom]

Don't you have to declare a param as "out" in order for it to be changed on
the outside?

There no out keyword in C++.

But when do you ever use it?

When programming in C++, barring mistakes and oversights, I always
write const correct code.

You could change it around and say, a param is
never modified, unless it is declared as out.

Sure, maybe I would if I was Bjarne Stroustrup and was designing the
language right now, but that's not how C++ works in this world.
Like I said, there's no such thing as an out keyword in C++.
When talking about C#, ref would be the relevant keyword.

Well, I agree with you. But, I rather see it the other way around. A method
never alters a param unless it is declared as such. Otherwise you 're
getting an awfull lot of consts.

Maybe that would be a good idea, but trying to implement it that way in C++
or C# would break just about every C++ and C# program in existance.

I know. Same thing as trying to program VB when you know Java.
Anyway, I had to . Had to write some compilers and 3d environments in C++.
But it took quite a getting used to in the beginning.

I didn't mean you should stick to just one language, what I meant was that
when
you learn a new language you need to do so with an open mind, not expecting
to be able to reuse the paradigms you're used to from another language.

<snip>

/Magnus Lidbom

 

[Harkos]

You really can't change a reference to an object parameter without the out
keyword. You still can pass a System.Windows.Forms.Control and change the
values of every property it has. His idea of a const keyword should be to
forbid this from happening.

[]'s,
Harkos

 

[Harkos]

Talking about inadequacies, the only thing I really really really miss in C#
is the throws declaration on methods. Sometimes it is a real pain in the
ass, but it sure keeps you from forgetting an exception.

I believe they didn't include this because property declarations differ a
bit from methods (although they also throw exceptions). Then why don't they
use these wonderful attributes they came with. It would be so easy.

[Throws (typeof(ArgumentException),
typeof(InvalidOperationException))]
public void DoSomething(object o) {
// ...
}

It could get a little big but it should work. Somebody could come up with a
3rd party compiler that could recognize these.

[]'s,
Harkos

 

[Frank Olorin Rizzi]

-----Original Message-----
Hi all,
I just thought I'd throw down what I think are the three biggest language
inadequacies of C#,

[..snip..]

I agree with you on the lack of const, and on the lack of
templates. I haven't done much with Interfaces, so I won't
say anything about that one.

However, I'd like to add one to the pile (and any feedback
is appreciated, of course):

[rant]

***** COULD WE PLEASE, please, PLEASE HAVE DEFAULT
PARAMETERS ? ****

I know we can come up with good reasons not to have them,
but geeeee.... am I the only one who misses them?

[/rant]

On the other hand, I ***LOVE*** Enums, but I'd like to be
able to define on the fly their ToString equivalents. For
instance, if I have

public enum myType
{
GOOD,
BAD,
SO_AN_SO
}

I always end up writing a statis converter for the enum
type:
public static string myTypeName(myType x)
{
switch(x)
{
case myType.GOOD: return "Good";
case myType.BAD: return "Bad";
case myType.SO_AND_SO: return "So and so";
default: return "???";
}
}

I'd rather be able to do something like
public enum myType
{
GOOD ("Good"),
BAD ("Bad"),
SO_AND_SO ("So and so")
}

Of course, the syntax is totally bogus,
but you get my meaning, I hope.

Who knows, maybe we'll see some of these suggestions have
a serious follow-up..

F.O.R.

 

[Magnus Lidbom]

Rearranged. Please don't top post.

Maybe I am wrong here but if you declare a param of a function with no
modifiers (out / ref ) then any chages that are made to the param inside the
method being invoked are only valid in the context of that method.

You are confusing canging what a reference refers to whith changing
the state of what a reference refers to.

Therby
making every param in C# default to a const.

The reference yes, the instance no.

<irrelevant code snipped>

String is immutable, hence your proof is fatally flawed. Try it with an
ordinary class:

using System;

namespace NoConst
{
class Test
{
private int m_test = 0;
public int TestVar
{
get
{
return m_test;
}
set
{
m_test = value;
}
}
}

class Tester
{
[STAThread]
static void Main(string[] args)
{
Test myVar = new Test();
Console.WriteLine("Value of myVar.TestVar is: {0}", myVar.TestVar);
Modify(myVar);
Console.WriteLine("Value of myVar.TestVar is: {0}", myVar.TestVar);
}

static void Modify(Test nonConst)
{
nonConst.TestVar = 5;
}
}
}

 

[Richard Cook]

It would be nice if the compiler issued a warning along the lines of
"assignment to pass-by-value parameter intest". Most likely such a line is
wrong because the coder:
is lazy, needing a var of that type and notices it's free for reuse
mistakenly thinks it will affect the caller (act as a ref/out param)
thinks he is assigning to an instance variable which the parameter is
hiding.

 

[Richard Cook]

Is const clever enough to detect invoking instance methods that change the
state of that instance?
Or would you expect it just to detect setting properties and public fields?

Rearranged. Please don't top post.

Maybe I am wrong here but if you declare a param of a function with no
modifiers (out / ref ) then any chages that are made to the param inside the
method being invoked are only valid in the context of that method.

You are confusing canging what a reference refers to whith changing
the state of what a reference refers to.

Therby
making every param in C# default to a const.

The reference yes, the instance no.

<irrelevant code snipped>

String is immutable, hence your proof is fatally flawed. Try it with an
ordinary class:

using System;

namespace NoConst
{
class Test
{
private int m_test = 0;
public int TestVar
{
get
{
return m_test;
}
set
{
m_test = value;
}
}
}

class Tester
{
[STAThread]
static void Main(string[] args)
{
Test myVar = new Test();
Console.WriteLine("Value of myVar.TestVar is: {0}", myVar.TestVar);
Modify(myVar);
Console.WriteLine("Value of myVar.TestVar is: {0}", myVar.TestVar);
}

static void Modify(Test nonConst)
{
nonConst.TestVar = 5;
}
}
}

 

[Magnus Lidbom]

Is const clever enough to detect invoking instance methods that change the
state of that instance?

It's clever enough in C++. Unless the member function is declared
as const you may not invoke it on a const reference or a pointer to const.

<snip>

/Magnus Lidbom

 

[Günter Prossliner]

It would be so easy.

[Throws (typeof(ArgumentException),
typeof(InvalidOperationException))]
public void DoSomething(object o) {

I think the implementation in own classes (with Attributes) would be
possible, but IMO the problem is, that this MetaData is not available from
other classes like the Base Class Libray (BCL), or componets from other
vendors.
Example: The the FileStream - class can throw an IOException, but it have,
and will never have, your Throws() - Attribute :-(
If your component uses the FileStream, and an IOException is not handled,
the exception have to be handled by the caller, who don't know that this
excption can be thrown by your component.

GP

 

[Magnus Lidbom]

See inline.



Eek, thank God they didn't. What a mess that is in C++.
you can cast it away, and then what good is it for?

You can cast just about anything to just about anything in C++.
Would you say that means type safety should be dropped?

From what I understand, const would be nearly impossible
in .NET due to the referencing scheme and end-around
things like reflection.

There's already an implemetation of a const CLI built upon
the shared source CLI: http://constcli.sscli.net/
Not impossible after all.

Personally, I've never had the need for const and I'm
not sure it would really be worth all the complexity
(and therefore bugs) and inconsistency it'd introduce.

Complexity? If you don't want const correctness you're
free to ignore it completely. The only time you'd ever
know it was there would be when the compiler saves you
from introducing a bug by stopping you from modifying an
object from some library that _does_ care about const correctness.

What inconsistency?

Const correctnesss introducing bugs? Can you come up with
a single scenario where that would happen? const correctness
_prevents_ bugs.

If you have a parameter that absolutely cannot
be modified, then you should use the built-in
protection mechanisms in the language to prevent it.

Which mechanisms would that be? I know of none,
only hacks such as writing interfaces that only expose
methods and properties that don't modify an instance.

If you're passing a bunch of wide-open classes
around and expect security, then you really aren't
designing well.

No kidding, that's what const correctness fixes, whithout
writing a million interfaces.

There are many arguments against const, unfortunately
I can't remember most of them. Basically, you should
either design for protection,

How do I do that without const and without writing a const
interface for every class i need to pass as const?

or make copies of
objects that cannot be modified.

Every time I want to pass an object to a method I should
make a copy of it first? Ever heard of overhead?

*sigh* I grow tired of the C++ guys coming to C# and
wanting to add in all the C++ garbage to C#. Templates
are another mess and subject to tons of abuse and misuse.

C++ templates offer incredible power to those who know how
to use them. What exactly is it about them that you find a mess?.

C# 2.0 (.NET 2.0) will have the concept of generics
which embody the good things about templates without
the bad things about templates.

Care to be more specific?

<snip>

/Magnus

 

[Chad Myers]

You can cast just about anything to just about anything in C++.
Would you say that means type safety should be dropped?

I don't care what they do in C++, that's why I use C#.
You can't cast away anything in C#. You can have the
argument in C++ group if you really care about it.

There's already an implemetation of a const CLI built upon
the shared source CLI: http://constcli.sscli.net/
Not impossible after all.

But is it complete? Is it whole, is there any way around it?
This issue has been addressed in the past by 'Softies and
they basically said that it is an extremely complicated
task, if not impossible and the benefits would be little
to none since there are design workarounds that are
even preferable to const anyhow.

Also, this isn't a Microsoft effort, the link you provided,
it's one guy who's yet another C++ holdover and he has
some nifty ideas, but I doubt he'll be able to produce
a full, stable release that doesn't have a bagillion
issues and problems.

I find it hard to believe that all the language
designers at MS working on C# going over and over
this for a few months couldn't come up with a solution
that'll be 100%, but this guy just came up with it
in a few weeks.

When he has working source and binaries that do it
and it works well, then I'll believe it.

Complexity? If you don't want const correctness you're
free to ignore it completely. The only time you'd ever
know it was there would be when the compiler saves you
from introducing a bug by stopping you from modifying an
object from some library that _does_ care about const correctness.

But what about if I'm using a library from some guy
who abused it and took advantage of the inconsistencies
and made a mess of it. In C#, you can do this in a
variety of ways, but it's pretty hard. It just seems
like const adds tons of complexity with no real value.

What inconsistency?

You can cast it away. It encourages poor OO design
and is inconsistent with other notions of code protection
in the .NET Framework and C#.

Const correctnesss introducing bugs? Can you come up with
a single scenario where that would happen? const correctness
_prevents_ bugs.

Not from what I've heard in C++ developers. It seems to
cause more problems than it's worth. I've yet to hear
a good argument FOR const parameters other than "it was
in C++ and I used it and liked it".

How does it fit with OO design? Does it make sense?
Is it consistent with other patterns in the framework?

I think the answer to all those is no.

Just because it's in C/C++ doesn't mean it's good,
in fact it's usually bad.

Which mechanisms would that be?

If you don't want certain parties modifying your
objects, then you should design your object heirarchy
to prevent against that. I have yet to see a situation
where const was necessary and there was no other,
more well-designed solution to the problem.

I know of none,
only hacks such as writing interfaces that only expose
methods and properties that don't modify an instance.

"hacks" like good OO design? I hear that a lot from
C++ guys. All those stupid objects and classes, who
needs them.

No kidding, that's what const correctness fixes, whithout
writing a million interfaces.

Const correctness "fixes" good OO design by giving
you a sloppy, inconsistent hack. Just make everything
public and use const, who needs well-designed objects
anyhow.

C++ templates offer incredible power to those who know how
to use them. What exactly is it about them that you find a mess?.

The lack of refinement and infinite potential for abuse.
Yes, I know, all features are abusable, but it seems
abusing templates in C++ is an artform.

Generics accomplish the most important parts of templates,
and I think it's a very good idea.

Care to be more specific?

Using templates for everything and anything whenever
possible. I've seen some particularly nasty abuses.
I just don't see the need for it other than generics
in .NET.

-c

 

[Nicholas Paldino [.NET/C# MVP]]

Jon,

I thought that something like this would be nice a long time ago, and
thinking about it more, it would still be nice. However, there is one block
that I have come up against which I think that some people aren't thinking
of.

That is, how can I reference an implementation of the interface on the
type level? Perhaps this is not phrased right. Fortunately, there is code:

// If I have a class MyClass which implements IMyInterface, I can do this:
IMyInterface pobjInterface = new MyClass();

And that is fine, because I have a reference to the interface and I know
there is an implementation behind it as long as the reference is not null.
Getting the implementation is easy, because instances are cast to the
interface.

Say that we can define static members on interfaces, so that
IMyInterface has a static property MyProperty. How exactly do I access this
on my interface? If I use this:

IMyInterface.MyProperty

Then there is no way to tell it should use the MyClass implementation of
IMyInterface for the static property implementation. If I use this:

MyClass.MyProperty

Then I am accessing the class directly, and I have no use for the
interface anyways. There is no way in the syntax currently which would
indicate that I want to use a particular implementation of the static
methods on the interface.

Any ideas?

 

[Jon Skeet]

I thought that something like this would be nice a long time ago, and
thinking about it more, it would still be nice. However, there is one block
that I have come up against which I think that some people aren't thinking
of.

Nah, people have been thinking about it all right

That is, how can I reference an implementation of the interface on the
type level?

By reflection. That's the only way. That's almost certainly why it
hasn't been available before. Now, however, reflection is being used
more and more, and that's where it's useful here. For instance, suppose
you had a plugin class - some driving class probes the target assembly
for all classes implementing a type, but then it's got to create an
instance. At the moment it has to call a specified constructor and hope
that the plugin developer has read the documentation which specifies
the constructor to provide.

This scheme would cause the plugin developer to get a compile-time
error if he didn't give the right constructor. The driving class could
still make a mistake and try to call a constructor or static method
which the interface doesn't define, but I don't think that's nearly
such a problem.

 

[Nicholas Paldino [.NET/C# MVP]]

Jon,

You could use reflection in this case, but given that, it would be
easier to just apply an attribute to the static methods on a type. The
process would be pretty much the same, and you don't gain anything from
having the interface define it as being static, as you would have to do an
implementation, but you couldn't access the implementation through the
interface (which seems downright hokey to me).