Language inadequacies

  • Thread starter Thread starter Darren Oakey
  • Start date Start date
Nicholas Paldino said:
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.

How does that help the compiler to give an error if the plugin
developer hasn't implemented the appropriate static methods or hasn't
provided a constructor of the right form?
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).

All you gain is compile-time safety for the plugin developer - but I
think that's a sufficiently big gain to make it worthwhile.
 
Jon,

It doesn't help to give the compiler an error. However, I do not
believe that additions to the language should be made for the sake of the
compiler. Rather, what I would rather see is the ability to hook into the
compilation process so that I can apply my own rules based on attributes and
how they are used.

You still come up against the issue of how to access the static
implementation, and at best, it is half a solution, and something I would
rather not see in the language for the sake of completeness. I can see how
it can be useful, but at the same time, it just seems half-done to me
without the other part to easily gain access to the implementation.

- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

-----Original Message-----
From: Jon Skeet [mailto:[email protected]]
Sent: Wednesday, August 20, 2003 3:36 PM
To: Nicholas Paldino
Subject: RE: Language inadequacies

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.

How does that help the compiler to give an error if the plugin developer
hasn't implemented the appropriate static methods or hasn't provided a
constructor of the right form?
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).

All you gain is compile-time safety for the plugin developer - but I think
that's a sufficiently big gain to make it worthwhile.

Jon
 
One way might be to allow access to the static property from the instance
variable. ie
pobjInterface.MyProperty refers to the static property on the concrete
runtime type of pobjInterface (or the closest superclass that has such a
method).




Nicholas Paldino said:
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?
 
Nicholas Paldino said:
It doesn't help to give the compiler an error. However, I do not
believe that additions to the language should be made for the sake of the
compiler.

It wouldn't be for the sake of the compiler - it would be for the sake
of the developer, who would suddenly start getting compile time errors
if they didn't do the right thing, rather than waiting until runtime.
Rather, what I would rather see is the ability to hook into the
compilation process so that I can apply my own rules based on attributes and
how they are used.

That could indeed be great, if done well.
You still come up against the issue of how to access the static
implementation, and at best, it is half a solution, and something I would
rather not see in the language for the sake of completeness. I can see how
it can be useful, but at the same time, it just seems half-done to me
without the other part to easily gain access to the implementation.

It's definitely only half a solution, but I think it's better than
nothing and doesn't actually detract from the language. Of course, if
someone can think of some nice syntax for the other half, that'd be
great :)
 
Unless I misunderstand: "Not from what I've heard in C++
developers" you're not even a C++ programmer, yet you feel
competent to debate the merits of how C++ implements const?

I started to write a reply rebutting your post point by point,
but I soon saw a pattern to your post: You didn't present
a single fact, nor a single example, to back upp your assertions,
just a lot of uninformed secondhand opinions and prejudices.

Feel free to write a new answer to my previous post if you have
any conclusions, or opinions, _with_ facts or examples to back them
up to present.

/Magnus Lidbom

<major snippage>
 
Looks like I'm going to be busy. Discussion inline...

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
Darren Oakey said:
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 :(

Whether or not const is good is a religious argument. Some think that const
is vital, and others think you shouldn't have it at all. I'll touch on the
high points, but I'll probably miss a few along the way.

The problem with const is that it makes your code inflexible. You're going
along, writing code, and suddenly you need to do something that makes a
const function non-const. You can either duplicate the function, or change
it from const to non-const and then patch all the calling functions. Or you
can cast const away, or in C++, you can use mutable. Neither of those are
terribly palatable, but at least C++ gives you an outlet (ie casting it
away). This does weaken the const guarantee so that objects are only
"visibly const", which is different from them being "truly const".

The other problem with const is that .net is a multi-language environment.
If you want const to be really useful, everybody needs to support it.

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

They weren't there from the beginning for a couple of reasons. The first was
one of resources - we simply couldn't get generics done in the time that we
had with a reasonable implementation. We explored doing a C++-like template
implementation that would have been compiler-only, but it didn't address
either boxing overhead or additional run-time casts, so we thought it was of
limited use.

The second reason is that we wanted to put enough effort into making sure we
get it right - both in the language and throughout all the libraries and
tools. That's taking a fair amount of effort right now, and I don't see how
we could have done that in V1.

I share your pain, however. I've been playing with generics, and it's a big
improvement.
 
--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
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".

We did decide to consciously trade off power for simplicity. For many (if
not most) programmers, advanced use of templates in C++ (and I'd include
metaprogramming in that class) results in code that is very difficult to
read, understand, debug, and maintain. I don't think I'm exaggerating if I
state that many people just don't understand that approach. Over time, some
of them can, but not all, and code like that often gets thrown out when the
original developer leaves.

C# explicitly values simplicity over power in a number of cases. If you're
used to C++, which typically values power over all else, some of our
decisions may seem strange.
 
Magnus Lidbom said:
Unless I misunderstand: "Not from what I've heard in C++
developers" you're not even a C++ programmer, yet you feel
competent to debate the merits of how C++ implements const?

I'm not a C++ expert, but I'm aware of all the things I'm
talking about and their plusses and minuses. I know several
C++ experts who have worked on many large C/C++ projects
and have mentioned on several occasions that templates
are a blessing and a curse. Some of them know .NET and they
are glad they are not in .NET, but they're glad to hear
that MS took the conservative approach with generics.

As far as consts, I know the construct and I know how it
would apply to .NET and I know that it's not a trivial
matter.
I started to write a reply rebutting your post point by point,
but I soon saw a pattern to your post: You didn't present
a single fact, nor a single example, to back upp your assertions,
just a lot of uninformed secondhand opinions and prejudices.

Well, I don't know what kind of facts you're looking for.

It's well known that there is a common OO argument against const.
Do I need to prove to you water is wet too?

There's also strong opinions against templates in Java and .NET.
I'm not going to google these for you, you're perfectly capable
of it.

It appears you are the one who is not up on the debate. You
seem like an old-time C++ guy who can't comprehend why people
wouldn't want to throw anything and everything including the
kitchen sink into a language and damn the people who think
it's messy, inconsistent and not standardized.

-c
 
It appears you are the one who is not up on the debate. You
seem like an old-time C++ guy who can't comprehend why people
wouldn't want to throw anything and everything including the
kitchen sink into a language and damn the people who think
it's messy, inconsistent and not standardized.

hmm.. have to step in here, even though you were attacking someone else..

a) const is hardly messy inconsistent or not standardized! It is a very
defensive tool. Many people now are realising that as coding gets out of
the cowboy corral that TESTING is more and more important - especially
regression tests.
Now, suppose you have the lines:

Point x = new Point( 5, 3 );
Point transformed = F(x);
Test.Assert( x.Equals( new Point(5,3)), "check that X hasn't been
changed");

In non-const world - that assert will not guarantee to pass. In a const
world... it will.
I put it to you:
without const (or some workaround, like const interfaces)
it is impossible to test anything more than a trivial example
with any degree of confidence, in any practical situation.

While you are correct that there are some OO people argue who against const,
OO is a good paradigm, but not the be-all and end-all of development. It is
very good for modelling a business problem. However, other paradigms, such
as functional programming, are vastly superior in almost every other way.
I believe a synergy of many programming techniques is the optimal solution,
as in MS's intentional programming model. In fact, we are already going
this way - you use a UI to produce your forms, and a designer to produce
your data types (datasets) - as time goes on, more and more people will
use the appropriate tool to solve the appropriate problem. OO only solves
one very specific part of the whole programming problem. (look up aspect
orientated development/workflows/etc etc)

C# is a general purpose programming language, so it handles simplistic
paradigms like structured design or stack based programming very well. It
also has been built with lots of OO features, so can be used for OO design,
development as well. The single keyword, const would give you a lot of the
benefit of a functional programming language! (In fact, iterators and
Anonymous methods (can you say lambda? :)) give you most of the rest of the
benefits.. (see
http://www.gotdotnet.com/team/csharp/learn/Future/default.aspx)

So - is const trivial? It almost singlehandedly brings a new tool to the
programmers arsenal, and if you look at the debates between functional and
other languages, one which is probably more important than the entire OO
enablement of the language put together.
I would say that any programmer not using at least a workaround of const,
such as const interfaces or events on all modifiers could not consider
themselves anything more than a beginner/intermediate coder.

b) as for templates: what's more messy/inconsistent/standardized?

Hashtable bad = new HashTable();
bad.Add( 1, "red" );
string theObjectIAmHopingLikeHellWillActuallyBeAString = (String) bad[ 1 ];

--- or ---

Hashtable good = new HashTable<int, string>();
good .Add( 1, "red" );
string theValue = bad[2];


and type safety is just one of a million different reasons good programmers
who code using generics use far less code, take far less time, and produce a
much more stable result than their specific compatriots.
 
Darren Oakey said:
hmm.. have to step in here, even though you were attacking someone else..

a) const is hardly messy inconsistent or not standardized! It is a very
defensive tool. Many people now are realising that as coding gets out of
the cowboy corral that TESTING is more and more important - especially
regression tests.
Now, suppose you have the lines:

Point x = new Point( 5, 3 );
Point transformed = F(x);
Test.Assert( x.Equals( new Point(5,3)), "check that X hasn't been
changed");

In non-const world - that assert will not guarantee to pass. In a const
world... it will.
I put it to you:
without const (or some workaround, like const interfaces)
it is impossible to test anything more than a trivial example
with any degree of confidence, in any practical situation.


Well, my point is that, I guess it's nice in a C world, but in a
nice, mostly-pure OO environment like C#, it doesn't make a lot of
sense. C# developers have come to expect that every language element
will work 100% of the time exactly how it's supposed to work
without any unintended side effects. Everything I've seen, read,
and experienced with const is that it doesn't live up to that.

There are several circumstances where const can be "gotten-around"
and it seems that if you depend on const for something, you have
failed in your design because you're trusting the runtime to
validate everything which, like I said -- from what I've read,
heard, seen -- cannot be done with const.

It's one of those features that for every time you would use it,
there's a better, and more elegant solution which doesn't use it.

If you must be absolutely certain that X will not change in your
example, and knowing that const can be cast away, why would you
even use it? Why not copy X or make a read-only wrapper for X?
While you are correct that there are some OO people argue who against const,
OO is a good paradigm, but not the be-all and end-all of development.
It is very good for modelling a business problem. However, other paradigms, such
as functional programming, are vastly superior in almost every other
way.

Well, that's where the conversation must end. This is what I was
talking about. Whenever there is a language feature debate with a
Java/.NET guy and a C++ guy, the C++ guy usually brings up that argument
that "OO isn't really that great" or "OO isn't the end-all be all".

Well, if you make up that argument, then yeah, C++ is a great
everything-and-the-kitchen sink language. But if you're mostly
a purist and believe that OO should be 99% of what you do, then const
is a fairly offensive notion.

b) as for templates: what's more messy/inconsistent/standardized?

Hashtable bad = new HashTable();
bad.Add( 1, "red" );
string theObjectIAmHopingLikeHellWillActuallyBeAString = (String)
bad[ 1 ];

C# Generics.
--- or ---

Hashtable good = new HashTable<int, string>();
good .Add( 1, "red" );
string theValue = bad[2];

C# Generics.

You also conviently left out all the other abuses and misuses of
templates
that are very prevalent in the C++ world.

-c
 
Another post with nothing but:
"I've heard someone say ...<unsubstantiated, vague attack on something>"
and
"You just want this because you believe in the wrong religion. The only true
religion is pure OO"

Not believing OO is the be all and end all of software development in no way
implies that you don't know OO. Your continued assertions that C++ programmers
don't understand OO, and hence all opinions of anyone who has ever used that
language is to be disregarded, is nonsensical. Unless you're well acquainted
with
OO you're not a good C++ programmer, you may be a good C programmer, but
definitely not a good C++ programmer. In my book you must be well acquainted
with the paradigms a language primarily support to be able to claim to be any
good with that language. If you're not, you're not even able to make an
informed
choice as to what paradigm is appropriate to solve a specific design problem.

/Magnus Lidbom
 
What I meant by proposing this ThrowsAttribute was a suggestion for
Microsoft to implement on, possibly, .NET Framework 1.2

[]'s,
Harkos
 
Why don't you put something up the compiler where you can flag if you want
or not to check these exceptions (like another cmd line param)? I've been
giving thoughts about the attribute idea and believe it becomes useful once
you can pick the exceptions list yourself from a MethodInfo.

Another work-around could be to generate only warnings for non-treated
exceptions, ignoring those signaled on the attribute. I agree with Hejlsberg
but I also think there should be a way of telling our API users what they
are to expect; allows us to create better applications.

[]'s,
Harkos

Eric Gunnerson said:
I think this interview with Anders should answer some of your questions:

http://www.artima.com/intv/handcuffs.html

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://blogs.gotdotnet.com/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.
Harkos said:
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
 
-----Original Message-----


I've worked around it like this:

[..snip..]
I know, I know... I do that all the times...
...but I just have an issue with things like:
hmm.. I have a class with 10 private fields.
When you instanciate an object of that class, you may know
none, some, or all of the values you wish to stick in the
10 fields.
So, the naive approach, since we have no default
parameters, is to have the following:
myClass() {...}
myClass(p1) {...}
myClass (p1, p2) {...}
myClass (p1, p3) {...}
....
myClass(p1, p10) {...}
myClass(p2, p3) {...}
....
myClass(p2, p10) {...}
myClass(p1, p2, p3) {...}
myClass(p1, p2, p4) {...}
and so on...

The approach I am using lately is to provide *ONLY* one
constructor, the "default" one:
myClass() {...set up all the fields with default values...}
and then provide setters for the fields, so that you can
set them as you need.

Is this elegant? nope.
Is it "right" ? nope, it forces me to provide setters for
all fields..
Is it always feasable? nope, sometimes I have classes with
fields that CANNOT have default values, and I am back to
the "naive" solution (granted, with a smaller set of
fields: only those that have no default)...

...but thanks for suggesting that, in case I had not done
so yet :-)
On the other hand, I ***LOVE*** Enums, but
[...]
I'd rather be able to do something like
public enum myType
{
GOOD ("Good"),
BAD ("Bad"),
SO_AND_SO ("So and so")
}

I suppose you could simulate it with a hash table whose keys are enum
members, but that's not pretty.

nope, and requires me to carry around a Hashtable...
(ok, you make it static and public, and you have it from
everywhere, instead of carrying it around, but
nonetheless...).

I think that it wouldn't be an *incredibly* difficult
thing to add, that's why I suggested it :-)

Then again, I'm sure someone will say that it adds a
complexity that is not needed :-)

F.O.R.
 
Magnus Lidbom said:
Another post with nothing but:
"I've heard someone say ...<unsubstantiated, vague attack on something>"
and
"You just want this because you believe in the wrong religion. The only true
religion is pure OO"

Not believing OO is the be all and end all of software development in no way
implies that you don't know OO. Your continued assertions that C++ programmers
don't understand OO, and hence all opinions of anyone who has ever used that
language is to be disregarded, is nonsensical. Unless you're well
acquainted

blah blah blah.

Look, at the end of the day, const is not good OO practice
and C# is a strong OO language based on OO principles.

If you don't like OO and you'd rather have const, then just
stick with C++ and quit trying to ruin our OO utopia.

We don't like const for a number of well argued reasons in
the context of OO. If you disagree with OO, then you're arguing
apples and oranges and we'll never get anywhere.

Make a strong case for const in an OO environment, and then
we have a discussion.

-c
 
Chad Myers said:
acquainted

blah blah blah.
Such eloquence.
Look, at the end of the day, const is not good OO practice
Why?

We don't like const for a number of well argued reasons in
the context of OO.
What reasons? You've yet to name _one_..
Make a strong case for const in an OO environment, and then
we have a discussion.

It allows a more precise specification of class interfaces by allowing a class
to promise that calling a get property, or a method, will not change the
observable state or behavior of the instance, it allows the passing around
of references to instances that the client must promise not to modify, and it
allows the compiler to verify at compile time that all these promises are
kept. It allows the programmer to make explicit parts of the contract between
a class and it's client that must be implicit without const, thereby
decreasing confusion, the number of times that the documentation must be
consulted, and preventing bugs.

How is this "bad OO"?

<snip>

/Magnus Lidbom
 
Frank Olorin Rizzi said:
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

You can use attributes. See this article:

http://www.codeproject.com/csharp/enumwithdescription.asp

<quote from article>
private enum MyColors
{
[Description("yuk!")] LightGreen = 0x012020,
[Description("nice :-)")] VeryDeepPink = 0x123456,
[Description("so what")] InvisibleGray = 0x456730,
[Description("no comment")] DeepestRed = 0xfafafa,
[Description("I give up")] PitchBlack = 0xffffff,
}

public static string GetDescription(Enum value)
{
FieldInfo fi= value.GetType().GetField(value.ToString());
DescriptionAttribute[] attributes =
(DescriptionAttribute[])fi.GetCustomAttributes(
typeof(DescriptionAttribute), false);
return (attributes.Length>0)?attributes[0].Description:value.ToString();
}
</quote>
 
Back
Top