|
James T. Johnson wrote:
Its not that they don't know about them; but why make it look like you are making an instance method call when it is a static method call?
Because it's more intuitive to the user of the class ?
James T. Johnson wrote:
Compiles just fine.
Apparently. 
James T. Johnson wrote:
This isn't language y, if you keep going back to wanting it to be language y you are are just going to infuriate yourself because it isn't.
That's fair, and more to the point, if I try to make C# behave like C++, I will miss out on cool stuff in C#. For example, I am getting into reflection and finding it very cool. But given that C# is clearly modelled at least in part on C++, it's reasonable to ask why this change was made, the syntax looks like C++ but behaves differently, so I assume they thought they had a good reason. I'm still waiting to hear it.
James T. Johnson wrote:
How is it counterintuitive? The method doesn't belong to an instance of the class, I think it is counterintuitive to code a static method call like it was an instance method.
I have a method I want to add to an XML wrapper class I am writing. It takes an XML node and goes through it's children looking for a text node. If it finds one, it returns the value. It's called GetText. I decided to make it static because it does not rely on the internal state of the class, but I imagine someone using an instance of the class to do other things would like to be able to type
myinstance.GetText(myinstance.FindNode("/XML/node/mynode"));
Being forced to remember what is a static method and what is not when all the methods are being used together to manipulate XML does not seem to me like a highly evolved thing to do. It's simply an annoyance.
James T. Johnson wrote:
All of the critics have lambasted VB for doing too many things for the developer on the language level, making them lazy. Oddly enough C++ does the same things but no one says a thing!
Like what ?
James T. Johnson wrote:
While we were working on the screensaver I think it is safe to say your biggest complaint was that you had to cast everything. Now we have a framework where a bad cast isn't going to ruin anything because the cast will throw an exception if it can't be made. I see that as a good thing. In fact it is close to the dynamic_cast of C++, a better match would be the as statement
I am reading the Richter book and now that I understand the as and is keywords, I think I like the C# model better than I did, but I still hate the fact that C# forces me to cast so much, especially in the case of the Clone method, containers, and using values supported in C# but not the CLR, like ( from memory ) short.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Like what ?
For one all the implicit casting, or at least judging by your comments about C# requiring so much casting I'm getting the impression that you rarely have to cast in C++.
But with having a strongly typed system, casting isn't the great evil it once was. You can't cast between types willy-nilly like you could with C so it isn't a bad thing to cast.
Implicit casting was the big language feature that everyone hated; I can't think of what my other issue was now. It probably had to do with static methods but that doesn't make much sense now. A lot of your casting issues could probably be done away with once generics are implemented [which reminds me I need to redownload CollectionGen  ], or if you used MC++.
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
I'm getting the impression that you rarely have to cast in C++.
Not so, but if I put a structure into a C++ container, I don't have to cast to pull it out. If I try to put an int into an unsigned char, I will get a warning rather than an error, if I have an object which has a clone method, it will return an instance of that object. Casting can happen in C++, but in C# it quickly becomes tiresome that it is ALWAYS assumed I am an idiot, or the language itself is too dumb to know what an object is when it should.
James T. Johnson wrote:
But with having a strongly typed system, casting isn't the great evil it once was. You can't cast between types willy-nilly like you could with C so it isn't a bad thing to cast.
That much may be true, my complaint is that it is tiresome and ugly.
James T. Johnson wrote:
A lot of your casting issues could probably be done away with once generics are implemented
Yes, I have high hopes for C# once it impliments generics, which are vital IMO to any modern language.
James T. Johnson wrote:
which reminds me I need to redownload CollectionGen
I could never make that work.
James T. Johnson wrote:
or if you used MC++.
Now you're REALLY swearing at me !!! :P
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
if I put a structure into a C++ container, I don't have to cast to pull it out.
This is more from having generics; not a language feature (I guess it is now but when the books I learned from were made they suggested staying away from STL  ). If you made the equivalent C# collections in C++ you would be casting to go from void* to whatever type.
Christian Graus wrote:
if I have an object which has a clone method, it will return an instance of that object.
This is the framework imposing its contract again. Depending on who designed the class that implements IClone(able?) you could have a strongly-typed version available. This is the same principle that ICollection works on (or is it IList?), the contract says there is an indexer that returns an object; but the class can also expose a strongly-typed version.
public class Foo : ICloneable
{
object ICloneable.Clone()
{
return Clone();
}
public Foo Clone()
{
Foo newFoo = new Foo();
return newFoo;
}
}Here you get the generic Clone() method if you specifically ask for the ICloneable interface; if you call the class' public Clone() method you get one that is strongly-typed. Strongly-typed collection classes should use the same technique so that they can correctly implement ICollection, IList, etc... I think this is my favor C# specific feature
Christian Graus wrote:
in C# it quickly becomes tiresome that it is ALWAYS assumed I am an idiot, or the language itself is too dumb to know what an object is when it should.
It just stops you from being lazy  Casting should only be required when it is unknown at compile time what type is returned (usually when you are dealing with methods that return object). In some cases generics could help that; but in others returning an object really is the only usage because it could be of any type *cough* void* *cough*.
Christian Graus wrote:
I could never make that work.
The first time I tried to use it I couldn't either; I haven't had problems since then. Maybe you should give it another shot? 
Christian Graus wrote:
Now you're REALLY swearing at me !!!
At least you could use some template classes to get away from casting so much Somewhere on my hard drive I have a prototype for a template class to wrap ArrayList Unfortunately it doesn't help you in C# 
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
when the books I learned from were made they suggested staying away from STL
Really ? How long ago ? That just seems like idiocy to me.
James T. Johnson wrote:
If you made the equivalent C# collections in C++ you would be casting to go from void* to whatever type.
Actually they used macros to create class factories. There was always a facility to create containers. But you're right, it's C$ woeful lack of generics that is the problem here.
James T. Johnson wrote:
I think this is my favor C# specific feature
Why does the GDI+ Bitmap not use it, I wonder ?
James T. Johnson wrote:
It just stops you from being lazy
And I'm supposed to be happy about this ? :P
James T. Johnson wrote:
Casting should only be required when it is unknown at compile time what type is returned
It is often needed because of numeric types of differing size as well.
James T. Johnson wrote:
Maybe you should give it another shot?
Perhaps. Partial template specialisation in C++ is still not here, so who knows how long C# generics will be ?
Thanks for taking the time to explain all of this to an old C++ hack. I still don't agree totally, but you certainly have once again helped just by letting me vent at you ( as you also did in the screensaver days ).
BTW how are you finding the memory leak detector ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Why does the GDI+ Bitmap not use it, I wonder ?
The 0-parameter version is inherited by the Image class which gives a return of object; but the GDI+ version of Image returns Image*. Perhaps the System.Drawing namespace was completed before the C# designers had thought to allow interface implementation to be done specifically?
There are two overloads to the Clone method which both return Bitmaps so those could be possible uses there.
Christian Graus wrote:
It is often needed because of numeric types of differing size as well.
True; I think this should be a warning instead of an error as well. But at least it doesn't do the conversion silently
Christian Graus wrote:
Partial template specialisation in C++
Can you explain what that is? I've seen it mentioned so many times but no explaination has ever been given
Christian Graus wrote:
who knows how long C# generics will be ?
From what was said before on the DOTNET lists there is supposed to be an interim release which adds this and CodeDOM support for MC++; but who knows if it'll get done in time.
Christian Graus wrote:
BTW how are you finding the memory leak detector ?
I haven't had a chance to use it yet; I've been in-between projects and working with Tom and Nish to get ready for writing our book. I have tried to keep up to date with the new releases as they come out.
I may get around to using it when I start my next project
James
"Java is free - and worth every penny." - Christian Graus
|
|
|
|
|
James T. Johnson wrote:
True; I think this should be a warning instead of an error as well. But at least it doesn't do the conversion silently
So we agree - the C++ way is better ( a warning, depending on the warning level set in the compiler )
James T. Johnson wrote:
Can you explain what that is? I've seen it mentioned so many times but no explaination has ever been given
A template allows you to specify a type, and essentially becomes a class factory. If I have a class that has two templated parameters, I could specialise that class by writing a version where both are int, so that this version is used if int is passed in. Partial template specialisation means I have more than one templated parameter and I specify what I want to happen if only ONE of them is a particular value, regardless of what the other value is.
James T. Johnson wrote:
I haven't had a chance to use it yet;
Me either, I've fired it up, but not found the time to really play with it. I'm writing a magazine article on C#/XML, and it's slow going.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Intel's compiler supports partial specialization.
|
|
|
|
|
Christian Graus wrote:
Perhaps. Partial template specialisation in C++ is still not here, so who knows how long C# generics will be ?
If you're really desperate try Eiffel .NET, which supports templates right now. Pretty expensive though.
Kevin
|
|
|
|
|
Christian Graus wrote:
I am reading the Richter book and now that I understand the as and is keywords, I think I like the C# model better than I did, but I still hate the fact that C# forces me to cast so much, especially in the case of the Clone method, containers, and using values supported in C# but not the CLR, like ( from memory ) short.
The C# design team also thinks it forces you to cast too much.
|
|
|
|
|
Cool - hopfully that means it will change in the future, I'm guessing when generics arrive ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Why ? I'll settle for one good reason
I doubt you will ever find a reason that you agree is sufficiently "good".
many people, myself and the designers of the c# language included, find it more correct and intuitive that a static belongs to the Type and not the Instance.
Apparently you will not accept that.
There is no other reason than thinking that that is the correct way to make consumers of the class member explicitly know the context and reprocussions of their using that member.
as for private statics being invisible in c#, that is simply untrue. I've use private static variables myself.
|
|
|
|
|
Andy Smith wrote:
many people, myself and the designers of the c# language included, find it more correct and intuitive that a static belongs to the Type and not the Instance.
Apparently you will not accept that.
No, because it benefits no-one but language lawyers, and makes using a class with static members less intuitive than in C++.
Andy Smith wrote:
There is no other reason than thinking that that is the correct way to make consumers of the class member explicitly know the context and reprocussions of their using that member.
So you're saying I'm not allowed to define a member function unless it alters the state of the underlying instance ?
Andy Smith wrote:
as for private statics being invisible in c#, that is simply untrue. I've use private static variables myself.
Well, given other design issues in C#, it was not an unreasonable guess.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
Myclass s;
System.MessageBox.Show(s.Myfunction()); // No way, no how.
This I find odd. This type of code would work correctly in Java. I'm surprised that it doesn't work that way in C#
Christian Graus wrote:
class Myclass
{
static public string Myfunction()
{
return "C# can be pretty dumb at times";
}
public string Myfunction()
{
return "C# can be pretty dumb at times";
}
}
Why do you see this as a problem. The compiler must be able to differentiate between a method at runtime and making this legal would add some abiguity to it. For instance.
<br />
MyClass s = new MyClass();<br />
s.MyFunction();<br />
In this case, which would be called? The static or the instance method?
Jared
jparsons@jparsons.org
www.prism.gatech.edu/~gte477n
|
|
|
|
|
jparsons wrote:
I'm surprised that it doesn't work that way in C#
Me too !!!
jparsons wrote:
Why do you see this as a problem.
The compiler will not accept it. I don't see the problem, the compiler does.
jparsons wrote:
In this case, which would be called? The static or the instance method?
The compiler won't allow both to exist.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian Graus wrote:
That SUCKS.
Even Stourstrup recommends you not to use static members thru' instance of a class. So I think it is perfectly ok that the language doesnot allow you to do that.
In fact I don't remember accessing static members through instances in the class ever. Though it is allowed I never do that.
Step back, rub your eyes, take a deep breath, stretch a bit, and reflect on the relative importance of CP, CG, the age / travel time sustained by supposedly 'fresh' cheese curds, and Life in General. - Shog9
|
|
|
|
|
Rama Krishna wrote:
In fact I don't remember accessing static members through instances in the class ever. Though it is allowed I never do that.
I did this a lot until a student of mine submitted the following code to me in Java.
<br />
SomeClass s = null;<br />
s.SomeStaticMethod()<br />
This code will work fine under Java. it doesn't throw any exceptions. After seeing this I stopped using static members through instnaces. Too nasty.
Jared
jparsons@jparsons.org
www.prism.gatech.edu/~gte477n
|
|
|
|
|
I don't remember exactly why we decided not to have const locals. It might have been that the CLR didn't want the complexity, or that we didn't want the language complexity.
On the static method issue, we found it weird that in C++ you could write something that *looked like* a method invocation but was really a static function call, or you could write it the other way. We also don't like having two ways of doing things.
|
|
|
|
|
Yes, I agree. I remember seeing an example in Java illustrating why it was good practice to use the static method format rather than the instance method (which, as in C++, is allowable in Java). Using the instance method format made the code very confusing. I'm pretty sure if the Java guys were designing Java again they would go for the C# approach.
Kevin
|
|
|
|
|
Kevin McFarlane wrote:
I'm pretty sure if the Java guys were designing Java again they would go for the C# approach.
Isn't it funny - Java is old enough now that it's designers must endure what Stroustrup has had since Java came out. I dunno how many interviews I have read where they ask him if he wishes he'd written C++ more like Java. I take my hat off to him for his measured and mature responses to this question. I hope the Java developers take a leaf out of his book.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
Christian,
I've seen one or two of these interviews too and he makes some good points. (Java enthusiasts can be fanatics. I hope that doesn't happen to C#ers!) You have to look at where languages are coming from, their design criteria, problem situations, etc., before you can properly assess them. Though, we all tend to have favourable or unfavourable first impressions. Having said that it seems that all language designers are especially biased towards their own languages and can be over the top on occasion.
In my case, although I have likes and dislikes, I've found that most mainstream languages have been palatable. For example, out of this list there's only one that I truly detest:
C, C++, Java, C#, Delphi, Pascal, Eiffel, Perl, Python, JavaScript, VB.
And that's Perl.
Kevin
|
|
|
|
|
Eric Gunnerson (msft) wrote:
I don't remember exactly why we decided not to have const locals. It might have been that the CLR didn't want the complexity, or that we didn't want the language complexity.
With all due respect, I don't see either of those as valid reasons to disallow me from creating constants as an aid to clarity and bulletproofing my code. Am I right in also thinking I cannot pass paramters into functions as const ? I was reading the Richter book on the bus and I was left with the impression that I cannot const reference types or my own value types at *all* ???
Eric Gunnerson (msft) wrote:
On the static method issue,
I guess it depends on how you look at it. I find it wierd to be using an instance of an object and have to chop and change between the object name and the instance name to use different methods.
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
it's a "valid reason" because language simplicity is a highly desirable feature in itself.
many c++ people are just not willing to give up feature x or y for the sake of simplicity. some see simplicity as marketing spin for not including their favorite feature.
however, many of us are glad that all this extra syntax and rules have been discarded.
|
|
|
|
|
Andy Smith wrote:
however, many of us are glad that all this extra syntax and rules have been discarded
I guess there is a place for programmers too stupid to learn a lot of syntax. If you can't appreciate the usefulness of const in C++, you're free not to use it, but my problem is that many of those dumbed down programmers may well work on my C# code, and I have one less way of protecting it from them.
If Microsoft wanted to move away from a lot of the useful stuff in C++ for some reason, they did themselves a disservice by making C# look so much like C++ that the missing features are blatantly obvious. I don't bag out Python for not having features in C++, but C# is MODELED on C++, so why get rid of so much good stuff ?
Christian
come on all you MS suckups, defend your sugar-daddy now. - Chris Losinger - 11/07/2002
|
|
|
|
|
you didn't need to resort to insults. My appreciation for simplicity and elegance does not indicate that I am stupid nor a danger to your code.
now that I have seen how you react to those who dare have a differing opinion, I don't think i'm going to waste my time on you anymore.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
