What is your prediction for .NET framework 4.0?

SecretSoftware wrote:



AndyC wrote:  SecretSoftware wrote:  Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking. if (someCondition) {    s = new string(); } else {    s = new int32(); } //what type is s here? Variant types like this are prone to misuse, bad for optimization and code analysis and just plain ugly.

s would be dependant on the condition. Initially s would be an object type and then its assigned to a string if someCondition is true, or if false would be assigned to a number.

This is present in other programming languages too, so its not a new thing.

You are missing the point here.  If I had code outside of the condition there would be no way to know what methods are avaible to s, meaning I would constantly have to use if conditions to determine the type of a variable before calling any methods on it.  Not that there aren't any benefits to this strategy but please leave C# alone and use javascript or another intepreted language.

John Gault wrote:



SecretSoftware wrote: AndyC wrote:  SecretSoftware wrote:  Well, the run time still can make type checking. What I mean is that the compiler should just infer the type of s from what its value type is, without writing extra keywords. This can be done while maintaining the type checking. if (someCondition) {    s = new string(); } else {    s = new int32(); } //what type is s here? Variant types like this are prone to misuse, bad for optimization and code analysis and just plain ugly. s would be dependant on the condition. Initially s would be an object type and then its assigned to a string if someCondition is true, or if false would be assigned to a number. This is present in other programming languages too, so its not a new thing.

You are missing the point here.  If I had code outside of the condition there would be no way to know what methods are avaible to s, meaning I would constantly have to use if conditions to determine the type of a variable before calling any methods on it.  Not that there aren't any benefits to this strategy but please leave C# alone and use javascript or another intepreted language.

We already have this in .NET 3.5, called var key word. And it Rocks!

We need  new an improved Compression classes in .NET Framework 4.0.

The GZipStream implementation needs to be improved for efficency and intuition by the end user. (you have to dispose the GZipStream object before obtaining the data as compressed data, counter intuitive for example).

Also, not only that, but we need a way to compress data based on what type it is. for example if I want to compress file data for storage , I should use the GZipStream, but if I want to compress other types of data, there should be a better compression class for that type of data. For example, there should be ways to encode and decode voice stream data or even video data. using speex, or ogg, or verbose.

so when I have some voice data captured from say the mixers, I would have to encode them with the speex codec class, on the fly and not depend on GZipStream for compression of in memory arrays.

So there is some avenue for expansion here. Afford us a way to encode/decode on the fly, and also to compress for achieve, right from the managed libraries in .NET framework.


PS: (Offcourse , developers could implement their own wrappers around codecs , but thats too much work, and it really should be something that the .NET Framework would take care of it for you.)


SecretSoftware wrote:

What do you think is missing from 3.0 and should be in 4.0? What are your expectations for C# 4.0?

It should be interesting to see what others think about what should be in 4.0 and what is missing that would make life easier for devs.


Thanks

Here's something that I'd like to see that I think would be fairly easy to implement:

using a reference type as a value type. Being able to instantiate a reference type on the stack and pass copies or by reference as I see fit.

Yes, I know all about value type, and why it was created and how to use it, but doggone it, I miss being able to instantiate any type -- like types I can't modify -- on the stack instead of in the heap. There were some really great benefits that are lost with the value type/reference type model.

True, if I really needed that functionality I could just slum it with C++/CLI, but then I'd lose all the great things about C# that make it so much better than C++.

Hi there and thanks to the team!

If "What features would you like to see the C# team add?" is really mean what it is saying then this is my wish list:
(I have implemented some of these in a library named Foop at https://sourceforge.net/projects/foop/ but without metaprogramming facilities or syntax extensions they are pretty ugly!)

1 - Define new operators; i.e. an operator named &&&.
2 - Define Generic operators; currently we can just overload the existing operators and if the operands are going to be Generic, they can only be of type of one of the Type Parameters of the container class.
3 - The pipe operator (|) as in F#; which can be there if we have feature number 2.
4 - Tuples; I have implemented some tuple data structures; but without compiler support, it needs to be implemented for any number of them!
5 - Better type inference; For example for lambdas I wrote a static method 'infer' for that I be able to define Extension Methods on delegates or use them in Anonymous Types:
new
{
    Target = "XPC 10",
    Vel = ExSyntax.infer ((int a) =>
    {
        return a * 22.8;
    })
};
or
ExSyntax.infer (() =>
{
    return DateTime.Now.Second > 10;
}).do_while_true (() =>
{
    Console.WriteLine ("Updating Report...");
});
6 - Anonymous Types everywhere; which in fact is "good Type Inference" every where. I think as the members of Anonymous Types are the static members of the container class; so we can apply synchronization and security facilities easily (I know you are the best and you are doing your best; so the "I think" part is just about the point of view from where that I am).
7 - Dynamic proxies; we can emit runtime types and cache them: declaring a new class that implements the target interface and has members of another type which is going to be have the interface (ducked!).
8 - Generic Generic Types; So I can define a typed linked list like this:
TyLList<A> {
    public A Value;
    public TyLList<?> Next;
}
9 - Named parameter calling for functions; for void F(int a, string b) calling it like F(b = "OK", a = 10)
10 - Default values for parameters
11 - Calling function with an Anonymous Type with members which are named after function arguments:
For void F(int a, string b) calling F like F(new { b="OK", a=100});
(We already have 9, 10 and 11 for attributes!)
12 - Metaprogramming; (not IL weaving) which already have proof of concept projects like F# (Active Patterns and Typed Quoting ...)
13 - An even very simple form of syntax extending; with 12 we will have enough of this
14 - A #light syntax for C#; as we have in F#, which can be some form of indentation-based code layout (like in F#) with possibility yet to enclose code blocks in {}s.
15 - Tagging types; which will provides us Class Cases, I have implemented for example Either<A,B>, some people implement this by declaring additional types like Left<A> and Right<B>; that is wrong! GADT are distingushed from the way that the object is constructed and the cases of the class in fact are different constructors which tag the object with different tags.
16 - 'this' refers to the current object; If there be somthing like this_type it is hand full (GetType is a runtime thing but this_type i.e. can be passed to Generics)
17 - Passing lambdas to attributes as parameter
18 - Defining Execution Contracts; like 'Ensure' and 'Requies' and with 14, even a new step in compiling a method or something.
19 - Capturing the values in the current execution context as a Name-Value dictionary; we have already the clousures and with 6, this would be very easy (this will provide us continuations).
20 - An attribute like [AloneExecutionPath] for methods; which grants that the methos just have access to it's parameters, and have not access to any public or internal thing in any assembly written by user (we can use .NET class library(is this good?) and to the Anonymous Types defined inside the function and we can pass objects of those types)
22 - Curry is necessary;
21 - OK! OK! ...
I was just looking into my codes and comming back here and write things! I close Visual Studio for now!
Maybe this is another language! Yet I do not think so!

Thanks all!

SecretSoftware said:

Basically when you have repetitive code that is similar in manipulation of things, but is different in minor areas, that it groups the similar stuff together into new methods, and arrange for the flow to be correct at the same time.

I'm sorry Dave. I'm afraid I can't do that ...