Jeremy D. Miller -- The Shade Tree Developer

The framework already has symbols.  It's called string interning.  The only fly in the ointment is that you can add to the interned strings list, but you can't delete from it.  However, for many purposes it's perfectly usable just the same.

bobondevelopment.com/.../optimize-memory-consumption-using-string-interning

I do agree that some syntax sugar would make string interning easier to use, though.

I don't think they're going to want break people's existing code by changing the default to virtual on methods.  But, I could see it being a compiler option that's off by default.

I'm with you 100% on mixins.  It's by far the most useful thing that multiple inheritance has to offer.  Presumably mixins could be implemented for significantly less effort than a full MI implementation.

C# vNext

#6 looks improbable.

One nice feature that came across my mind the other day would be a even better syntax for passing an anonymous delegate to a method. I'm specifically trying to get a similar syntax as in Ruby, where a block can be passed as the last argument to a method and the syntax looks oh so natural:

//C# 4 from a dream

Transaction.Scope() : with (trx)

{

  obj1.DoSomething();

  obj2.DoStuff();

  if(obj2.Failed) trx.RollBack();

} //commits by default.

File.Create("error.log") : with (f)

{

  f.WriteLine(someException.ToString());

  f.WriteLine("Error at {0:d}", DateTime.Now);

} //file will be released here

pdfDoc.CreatePage() : with (page1)

{

  page1.MarginSize = 2;

  //..more stuff...

  page1.CreateParagraph() : with (par)

  {

     par.Align = Align.Center;

     par.AppendText(" blah blah blah...");

   }

}

I got carried away, but I hope the idea makes sense.

You've been kicked (a good thing) - Trackback from DotNetKicks.com

C# vNext, pause. VS vNext all-hands-on-deck

@Sergio: Most of the things you describe are already available in C# with similar (and not much more) syntax.  The using(){} block would handle everything you show there except the automatic commit of the Transaction Scope. But you could easily make an IDisposable wrapper class for that (a la MockRepository.Record() in Rhino.Mocks).

@Bob:

Ruby's Symbols are interned Strings as well. The C method to get a Symbol is actually rb_intern() IIRC. They also suffer from the same drawbacks (they can't be removed once added to a process). Which is why you should use them with care.

A Symbol to represent a column or action name: Sure thing. A small finite set and nice performance gains.

A Symbol to represent a user-name: Bad idea. Basically an infinite set that will crowd the symbol table and drag down performance across the board as a result.

@Jeremy:

Heh... default-virtual. I've been saying that for years. :-)

Your list doesn't really sound like c# vnext.  It sounds more like Ruby.

And that's "on the way".. :-)

Evan

Does this resolve mixins?

msdn2.microsoft.com/.../bb625996.aspx

Compile-time metaprogramming ala languages like Converge (digg.com/.../446482).  Having the ability to define new syntactical constructs like you can with Lisp's defmacro could be very powerful and eliminate a lot of boilerplate code.

AOP is important, other things (like everything virtual or hashes) are out of place. Symbols seem dangerous, since they create an illusion of being compiler-checked.

What if symbols really were compiler-checked?  No illusion then :-)  <a href="dotnet.agilekiwi.com/.../symbols-part-3.html">This page</a> links to several ideas that I've either linked to or posted myself.  

As for mixins, here's one suggested way to do them, <a href="kirillosenkov.blogspot.com/.../john-rusk-on-extension-interfaces.html">extension interfaces</a>.

Proper support for design by contract. You can only do this properly with support from the compiler, and it has to be a language issue.

That removes the need for a lot of unit testing.

The unit testing is better replaced with code analysis and automated unit testing.

@cmyers

Oh, I knew that. But it's not the same thing as having syntax to support it. Furthermore, that would enable the disposable object to more easily enforce the disposal of any required resource, commit what needs to be committed, destroy scopes, etc. Think about the File.Create example above, the logic to properly dispose the file handle could be baked inside that File class for everyone to reuse if desired.

//File class

public static void Create(string path, FileBuilder theDelegate)

{

 using(StreamWriter file = new StreamWriter(path, false))

 {

   theDelegate( file );

 }

}

Another example, how many times we have written code to process a file line by line...

public static void EachLine(string path, FileLineProcessor theDelegate)

{

 using(StreamReader reader = new StreamReader(path))

 {

    string line = reader.ReadLine();

    while(line != null)

    {

       theDelegate( line );

       line = reader.ReadLine();

    }

 }

}

// usage:

List<string> commentBlocks = new List<string>();

File.EachLine("myclass.cs") : with (line)

{

 if(line.Contains("///")

    commentBlocks.Add( line );

}

I don't know ... To me it just seems like something that could add value to the language.

C# yNext?  Microsoft quit changing things on us.  Give us a break so we can get some work done without learning all the new crap all the time.  It makes me cringe every time I hear about some new cool feature I will never use.  Please MS, stop the friendly fire!

Agreed; stop changing things so much.

Curious why people think static languages are going the way of the dinosaur?

built-in design-by-contract support.

@CV

C'mon. Are you're seriously complaining about evolution? The C# language team has been pretty good at not introducing breaking syntax changes.  You can elect not to learn the new stuff and continue writing using the 1.0 syntax if that makes you happy.

Or are you complaining about software development in general?

Everything virtual by default....oh yes please (crazy that it isnt like that already)

I'd like to be able to do something like

List<object> objectListHoldingStrings = new List<string>();

Extensible compiler pipeline...

I want the ability to use (and build) custom attributes that will be executed during compilation.  An example today is the [Obsolete] attribute, which shows a compiler warning..

These custom attributes would derive from specific base classes to determine functionality.  A good example is to look at the functionality exposed by PostSharp.  Some features:

 * IL rewriting

 * Validation

 * AOP

Extensible compiler pipeline - a-la Boo

Jeremy, get a chance and look at the Nemerle (nemerle.org). It is already has a great metaprogramming subsystem. It is amazing!

I want multiple return values like:

return 0, 1, 3;

var x,y,z = myFunction();

Ignore the second return value:

var x,,z = myFunction();

Mixins in c# 3.0

Opps.  Those links didn't come through properly.

The one about mixins is: kirillosenkov.blogspot.com/.../john-rusk-on-extension-interfaces.html

The one about symbols is: dotnet.agilekiwi.com/.../symbols-part-3.html

and also this discussion on MS's site covers symbols too: forums.microsoft.com/.../ShowPost.aspx

Mixins could be implemented by extending generics so you could do generic inheritance like this:

class Mixin<T> : T {

 ...

}

Then you can use the mixin to extend a string like this:

Mixin<string> mixinString;

Definitly non-nullable type:

codebetter.com/.../i-want-non-nullable-types-in-c-4.aspx

Neat and dramatically helpful.

Mixins in C#

One thing I'd like to see, which I'd consider more of a bug-fix to v2 than a new feature for v3, is something which I've been calling a "contract".  It would essestially be an interface on steroids, and only used in generic contraints.  I would be like in interface, but could also specify other things that the class must implement/have available, such as static members, operators, and ctor parameters,

I agree with the above and add:

A) I'd like a way to specify that variables should be disposed of, within the current method, after they are last referenced (and in the relevant finally statements).  This should not be too hard, since the compiler knows the last time they were referenced (this is required for .NET garbage collection).  Unfortunately, this feature might break the "pit of success" goal for .NET.

B) Ability to refactor an anonymous type into a declared type.  This is not currently possible if one wishes to retain the named parameter approach over the constructor approach (new Foo() { Bar = 2 } vs. new Foo(2)) and get immutability.  There is no way to allow the former kind of assignment with readonly fields/properties (only the constructor has permission to write to them).

C) A possible alternative to B, and very useful in its own right: named parameters.  Calling a method and passing (true, true, false, true) is not readable at all, or as Scott Bellware would say, _soluble_.

D) Better type inference.  This is a hairy issue, to which anyone who has debugged Haskell type errors can attest.  However, I think excellent IDE support would mitigate this issue.  Being able to access anonymous types, strongly typed, outside of the method in which they were declared, would be quite helpful, especially for rapid, prototype work.  It should be possible to use refactoring tools to make types explicit if necessary.

@Jeremy Miller: your justification for making everything virtual by default is really a hack, IMHO.  Eric Lippert has an excellent blog post on why most of the .NET framework classes are sealed [1] that addresses this issue.  In short, unless your methods are designed to be overridden, you are making them virtual only for testing purposes and in doing so, someone can override them in a way for which you did not plan.  Eric Gunnerson also discusses this [2] and there is a decent amount of discussion in the comments.  Virtual by default is also a performance issue, which is one thing I think the Java HotSpot optimizer was built to overcome: figuring out which virtual methods are never overridden so that the vtable call can be elided.

[1] blogs.msdn.com/.../61803.aspx

[2] blogs.msdn.com/.../133570.aspx

@Chuggle: List<object> objectListHoldingStrings = new List<string>(); is tricky business.  C# allows you to do this with arrays in a very hacky, non C#-ish manner because Java allows it:

object[] objs = new string[1];

objs[0] = 2; // ArrayTypeMismatchException

There are a few options:

1) make the lvalue immutable: acceptable (List<object> becomes ReadOnlyCollection<object>)

2) copy the list: undesirable because, IMHO, it violates the principle of least surprise

3) allow contravariance with IEnumerable<T>, as it is immutable

there is a language that is much like what you seem to be asking for: The D Programming Language. Even If you don't want to use it, it would let you get your hands dirty with a language that has most of what you are asking for. 1, 3, 5 and 6 for sure, maybe 4 and I don't know what 2 is but it might have it.

http://www.digitalmars.com/D

a clarification: D has a type of mixins, if it's the type you are looking for is another matter.

BCS, not just mixins, D actually has more/less everything mentioned in the article - some of those for years (already years passed, phewww).

Mr. Miller, so much for "static typed languages are closing in on being an evolutionary dead end" talk...

Kind regards

Mixin's rock!

Everytime I read your blog you come over as a complete moron...

One feature I admire in Groovy is the "?." operator. As I understand it, it allows you to traverse objects but stop if one of the objects turns out to be null. For example the expression "foo.Bar.Baz" will throw a NullReferenceException if the "Bar" property happens to return null, but "foo.?Bar.?Baz" will return null when the first null is encountered.

Generic covariance and contravariance.  When you need it, you really really need it.

And doesn't virtual by default make it more difficult to abide by LSP?  Seems like that can be solved with products like TypeMock and techniques like "subclass and override".

I reckon more ruby like features as mention in the article, what I would really love is being able to pass a block into a conditional statements

for example

return error_msg if !person.isValid()

I would also love to see the allowed use ? for boolean statements and the unless keyword, although not the most critical features ever, they do make for more elegent code

I'd like to see design-by-contract concepts into C#.

This would clean up code significantly -- imagine something like a [NotNull] attribute on your params instead of writing a million different null arg checks.

It would result in a codebase with fewer bugs.

I'd also like to see more functional concepts in C#: Spec#'s research is promising and also could result in code with fewer bugs.

That's what I ultimately want. Metaprogramming and AOP is nice, but really what I want is fewer bugs in my code. I want language and runtime help with this. Design by contract is one such way to accomplish this.

@Sergio: There's no need for anything beyond C# 3 to make line handling easy.

I've already written a LineReader : IEnumerable<string> class (very simply - it's not like it took a brainwave to come up with it) where you pass in enough information to make a TextReader *at the right time*. That "right time" is when GetEnumerator() is called. You can then do:

(Apologies for spacing issues - nasty proportional font...)

foreach (string line in new LineReader(...))

{

}

The file will be closed at the end of the foreach.

*And* you can use it very nicely in LINQ:

var query = from log in Directory.GetFiles(logDirectory, "*.log")

   from line in new LineReader(log)

   let entry = new LogEntry(line)

   where entry.Type = EntryType.Error

   select entry.SourceIPAddress;

Bingo, you now know all the source IP addresses which encountered errors, across many log files, only ever loading a line at a time, with pretty much no fluff in the code to get there.

LINQ to Objects rocks, and people aren't making *nearly* enough fuss about it...

Jon

Nothing, absolutely nothing. The C# syntax is being more complicated and complex. I would focus on extending .NET library instead of useless features in the language.

All the Linq stuff is very interesting at first glance but when one starts working with that, he realizes that it does only very simple things. Linq to SQL is just veeeery simple mechanism good for fetching data from Notrhwind database. When you want to use it with advanced logic (with stored procedures in DB) it becomes useless. Even Scott Guthrie wasn't able to help me and said something like "Sorry, it's impossible". ;) MS should work on that harder because it's a veeery long way in front of them to create a good ORM.

@SirMike: Don't make the mistake of thinking that LINQ=LINQ to SQL, or that LINQ to SQL is the only LINQ to databases provider.

For in-process stuff, a lot of what you can do in LINQ can certainly be done without LINQ - but LINQ makes it cleaner, more readable, and generally nicer.

Jon

"Nothing, absolutely nothing. The C# syntax is being more complicated and complex. I would focus on extending .NET library instead of useless features in the language."

It's inevitable to get replies like this it seems. If a feature is useless to you, don't use it. But why should we suffer under your incompetence by not having these features at all?

Also, since do we have to choose between language features and library development? Did not .NET 3.5 introduce both (new C#/VB compilers AND new namespaces such as System.Linq).

Please use brain before posting, kthx!

Mixins in C#

Pingback from  &raquo; Daily Dose of Links - 20071205 Alvin Ashcraft&#8217;s Daily Geek Bits: Daily links plus random ramblings about development, gadgets and raising rugrats.

Microsoft must stop changing C# so much, so fast. Instead they should make a 3rd language mainstream, Something between F# and Scala. Sure I will use it. Because for me, I must hack the shortages in C# and some bad designed aspects of it. For example generics are so limited in C# that it is in many scenarios useless. I want higher order data types and higher order structure of data (like lisp) and higher order data structures.

It seems Scala is a good choice. But it is on JVM. And F# with a more polished syntax and a good support can be it for sure!

A couple months ago I made a post called What do you want in C# vNext? that outlined what *I* wanted

Personally, I'd like to see automatic properties enhanced so that, while they would still generate the backing store, they would access it via programmer-defined methods.  Keeps the conciseness of the currrent automatic properties, but adds a lot more power: dotnet.agilekiwi.com/.../enhanced-automatic-properties.html