…unreceptive to change…

In my “Minus 100 points” article, Shawn took me to task for the reasons why we didn’t put ‘with’ in the language.

Unreceptive to change is, when I think about it a bit, probably a true statement. We are fairly unreceptive to change – it took a lot of customer feedback to get us to change our stance on accessibility for properties. I don’t think that is necessarily a bad thing – I think the best languages were designed either by a single person or by small groups, and I’m not a big fan of languages designed by committee (Ada comes to mind…). The C# Language Design Team is a benevolent dictatorship – we all have our say, but Anders is the overall custodian of the language design. I think that’s important if a language is going to stay true to its philosophy.

On a specific issue, we might appear unreceptive for a number of reasons.

The first reason is that your request is probably not the first time we have heard such a request. We do take note of them (see property example above), but in most cases we’ve already spent a considerable amount of design time on the issue (by that I mean hours). In the case of ‘with’, we looked at what other languages had done, how well the construct worked, and then made the call on whether we thought it would be good to add it. We have a considerable amount of language design experience and familiarity on the team, which means we generally know the prior art fairly well. I’m sorry if this comes of as arrogant at times – we’re working at doing a better job of communicating in this area.

‘With’ was a very conscious decision, especially because it’s present in both Pascal and Delphi, Anders’ previous babies (okay, Pascal was really Wirth’s baby, but Anders was involved with one of the more popular variants).

As I said, we might choose to add it in the future, but given the divided nature of the customer feedback that we get, it’s likely that we’ll stay where we are.

Eric, could you comment on the absence of co-variant return types? I’m sure there was a good reason for not allowing them in c#, but the framework seems to support them. Did the BCL and c# teams simply disagree on this issue?

One thing I was disappointed in, was the lack of an ‘until’ keyword. I would be interested in whether it was considered and, if so, why it was rejected. Whilst it doesn’t add much that isn’t already there it can help to author more readable code, which is always good? 🙂

I think it’s great that the C# Design Team don’t bend easily (can’t say that much about the VB team ;)). Anders obviously knows what he’s doing and I think it’s better for all of us that way, even if we don’t like it sometimes. Over time, I think we’ll appreciate it more (hey, I’m already beginning to think that .default isn’t that bad).

Just curious, was Anders the one who really pushed the idea of not using "with"? Did he have bad experiences that involved "with" in Delphi?? I may be reading between the lines a bit. 😉

Personally, I’d like to see "with" included. There are ways to actually fix it so that it is a productivity improvement while still keeping it clean in the sense that it won’t create confusion and "newbie errors".

My recommendation would be to adopt the VB "." prefix requirement. That works well for both productivity aids (intellisense) and for readability. The other issue is the scope- the ‘with variable’ must be at the highest level within the scope.

BTW, the problem with not having "with" is that everyone now defines a stupid short variable name and it makes the code pretty messy, for example:

SomeObject sip = someInstance.someProperty;

sip.AProperty = 5;

sip.BProperty = 15.5;

sip.DoSomething();

sip.DoAnotherThing();

Maybe its just a personal preference thing, but I really don’t like this. I think it makes the code less readable.

I’m one of the "customers" who 100% agrees with leaving ‘with’ out of the language. My arguments against it all center around it promoting bad coding. For example, in my experience of VB4 onwards, many developers (myself included) write:

With SomeObject.GetFoo.GetBar.GetResult

.SomeMethod()

…

End With

When in fact, all statements within the with block should be pushed down into a new method defined on the class returned from GetResult. The code (in VB) would then look like:

SomeObject.GetFoo.GetBar.GetResult.DoSomeWork()

and then:

Sub DoSomeWork()

Me.SomeMethod()

…

End Sub

I’ve also seen code which does the following:

With SomeVariable

.DoSomething

‘ 150 lines of other code

.DoSomethingElse

End With

When you scroll to the bottom of the screen and read the ".DoSomethingElse" statement, you have no idea which object it is referring – and it tends to be quite difficult to scroll back up 150 lines and match up the indentation to work it out!

In the end, I believe that any need for a With statement can be replaced with a little bit of disciplined refactoring.

At least in vb, I have found the with statement to improve readability. It can greatly reduce the amount of code you have to look at or type. The less code you have to look at, the more readable it becomes. In the case of the with statement, you just have to remember what the with is refering to establishes the context of all that follows.

In place of the with, one can simply use an object variable at the beginning of each line. This is what the compiler does — which is the reason why there is no performance difference.

Not sure how the apparent need for a with(…){} would be indicative of a real need for refactoring. I suppose this indicates I should take a closer look at refactoring.

In any case, I can understand why some would be interested in having the with statement. At the same time, I can certainly see why it didn’t make the 100 "language additions are forever" points need for inclusion. While I am found of "With … End With," I would (at least for the time being) have to go with the C# team on this one.

Just wanted to provide a quick explanation of "different levels of accessibility" for Alex. Levels of accessibility would be public, internal, private (I am leave one out?), and as C# is currently written, the "get" and the "set" of a property must be at the same level, assuming both exist, since the level of accessibility is a characteristic of the property, not the accessor ("get" or "set").

private string mFoo;

public string Foo

{

get{return mFoo;}

set{mFoo = value;}

}

However, it may be the case that a given programmer wants the property "foo" to be read-only outside of a given module (by consumers of the module) yet read ("get") and write ("set") within the module. Currently, to this, you need to create an internal method with a less obvious name (e.g., "internal SetFoo") for writing. Giving the accessors "get" and "set" different levels of accessibility (public/internal/private) simply means that that a level of accessibility may be an attribute of the accessor (so that we might have, for example "internal set" rather than just set), not just the property.

I’m a Pascal programmer (in fact, my first compiled language was that "popular variant" that Anders was involved with…) so I have no fear of the with statement; it’s certainly ironic that the same C++ programmers who fear it think nothing of the inane switch/case statement; I’m glad C# fixed that!

I think Ada has a better syntax. From memory it was something like "scope VAR: EXPRESSION do … end;", tho I may be misremembering. The difference is that, where Pascal uses "with ShapeObj.Area.TopLeft do x := 42;", Ada uses

"scope Pt: ShapeObj.Area.TopLeft do Pt.x := 42; end;" The result is to create a sort of alias for the complicated expression, and use it without compiler penalty.

I like it. I miss it, tho I never used Ada much. Presumably if you use a temporary variable tho, an optimising compiler will do the same, with added type checking, in most languages as they are.