Linked by Thom Holwerda on Sun 12th Jul 2009 21:29 UTC
Thread beginning with comment 373127
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Garbage collection has everything to do with it. The garbage collection system takes over responsibility for resource deallocation. you use a language with GC, you accept that. Managed C++ has GC features but that is more a function of being compiled to IL code rather than it being a central feature of the language.
C# is an evolving mixed paradigm language. it is both imperative and adding Functional features to support interesting things in the framework.
As to what you want to do with Static methods, you want it to work in a way you like rather than a way it is meant to work. You want to add static features? you will have to subclass it. It certainly should never be able to be done at run time.
Edited 2009-07-13 19:34 UTC
Garbage collection has everything to do with it. The garbage collection system takes over responsibility for resource deallocation.
Garbage collection takes over responsibility for memory deallocation. For more valuable resources such as windows handles and file handles, you need a more precise mechanism. C++ provides such a mechanism. And so does C++/CLI. But C# does not (there is no way to enforce that somebody calls Dispose() on your object implementing IDisposable).
you use a language with GC, you accept that. Managed C++ has GC features but that is more a function of being compiled to IL code rather than it being a central feature of the language.
Managed C++ has both. You can have garbage collected object (allocated with gcnew) that gets garbage collected, but you can also use RAII since you can have deterministic destructors that get called when the object goes out of scope.
C# is an evolving mixed paradigm language. it is both imperative and adding Functional features to support interesting things in the framework.
You can't really call it functional because it has very little support for immutable data structures. Immutability is a prerequisite for referential transparency, and referential transparency is the core property of functional languages.
As to what you want to do with Static methods, you want it to work in a way you like rather than a way it is meant to work. You want to add static features? you will have to subclass it. It certainly should never be able to be done at run time.
I don't want to do anything at runtime. I would just like to add static methods to existing types, since static methods are (unfortunately) very common in C#.
If you write the type name and a dot, you get the list of all public static methods of this type and its base types. I would like to add a method to this list.
An example would be adding a Parse<T>(string) method to System.Enum.
Whether adding methods to existing types/instances is a good idea is another topic. But if one is possible, then the other should be possible as well.
By the way: enums are another topic where C# is broken. Why is it not possible to use enums as type parameters? And why do enums not implement the IEquatable<T> interface?
I think static methods and fields are a stupid idea in the first place. That is why they don't exist in well-designed languages like scala.
C# is an evolving mixed paradigm language. it is both imperative and adding Functional features to support interesting things in the framework.
The problem is that those additions do not fully integrate with the features already there, making the whole language a bloated mess of conflicting paradigms. Right now it's just a grab bag of containing every 'flavor of the month' programming gimmick, but no actual coherence between those features.
As to what you want to do with Static methods, you want it to work in a way you like rather than a way it is meant to work. You want to add static features? you will have to subclass it. It certainly should never be able to be done at run time.
Extensions methods are a compile time feature, not runtime.
And "the way it is meant to work" is what exactly we are complaining about. The way the designers meant the feature to be used makes it non-orthogonal to the features the language already possesses.






Member since:
2006-03-01
Garbage collection has nothing to do with it. If an object (like a file or a GDI brush) has some resources associated with it, I want them to be deallocated immediately when the object goes out of scope, and not a few minutes later when the object is garbage collected.
There is the IDisposable interface and the using(...)-Pattern, but there is no way to enforce this. That is why C++ (even managed C++) has destructors that get called immediately. RAII is tremendously useful, but impossible to do safely in C#.
What does that have to do with functional programming? C# is not a functional language. It is just a language that took a few features (closures) from functional programming without understanding the big picture. For example, the biggest property of functional languages is referential transparency. But it is very difficult to ensure immutability in C#. In fact most language patterns (property and array initializer syntax) encourage mutable objects.
Scala has none of the deficiencies I mentioned and is much more functional than C#.
I want to be able to add a static method to a type. To be precise, I do not want any static methods in the first place. I would prefer the scala approach.
But if you have a language feature like static methods or interfaces you should make sure that other language features (operators, extension methods) work together with that feature. Otherwise the language is nonorthogonal, which is just bad design.