C# Syntax – How to Avoid Repetitious Object Instantiation

csyntax

When learning C# (and OO concepts more generally at the same time) something I found very distracting is exemplified by the following line:

ExampleClass exampleObject = new ExampleClass();

It's the apparent redundant repetition that bothered me. Some light dawned when I grasped the difference between declaring a variable and assigning it a value or reference (and that these processes can be separate). However, the above usage is extremely common.

Obviously, I've learnt to live with it (and am not expecting the C# syntax to change!) but I wondered if there is a better way. Would there be any merit in the following:

exampleObject = new ExampleClass();

Where the variable exampleObject is strongly typed as ExampleClass when it is not specified?

EDIT
[after commenters pointed out ambiguity of above between a declaration of a new, and an assignment, of an existing, variable:]

An alternative hypothetical shortened syntax, which avoids the declaration/assignment ambiguity, is:

ExampleClass exampleObject = new();

…where this would create a new instance of ExampleClass, the type having been specified in the declaration of its referencing variable, exampleObject.

.. but I'm sure this opens up other problems I haven't thought of!

/EDIT

Obviously, if for some reason we wanted exampleObjectto be of type Object, or – a more common requirement – to be of the type of a parent class of ExampleClass, we would specify these types in front of the variable name in the standard way, but is there any drawback to my suggested shorthand in this very common scenario?

Best Answer

C# requires you to explicitly declare a variable, in addition to assigning it a value. This is done so that its clearer to both the compiler and the person reading the code that we're defining a new variable here, not using a previously-defined one, which can simplify parsing and make the code much clearer.

As you said, the statement ExampleClass c = new ExampleClass() is simply a contraction of both these actions, which is why you feel the duplication - it's two different actions. But it does feel clunky. This is why the C# 3.0 specifications (in VS2008) added the var keyword, which lets you skip a lot of the verbosity, even if it wasn't the primary motivation for the feature.

Using var, our example code becomes var c = new ExampleClass() - much easier to scan, but still explicitly declaring as well as assigning. It gets even more useful with long class names - var complexDictionary = new Dictionary<Tuple<int,int>, List<string>>(), for instance. Imagine writing that twice!

Of course, var was originally introduced to support anonymous types. These are used by lambda expressions and LINQ, and create types with names that are both clumsy (MyMethod<>Class5, or similar) and also not known to the developer, so that saves us a lot of problems.

Additionally, in your edit, you proposed a similar but inverse solution to the duplication - to keep the declaration explicit, but the instantiation implicit. This saves about as many characters as var, but is a lot less flexible. Consider that variable declaration is very simple - you simply state the type of your variable. Initialization, though, is more complex. Sometimes you simply use new, and then we can use your new() syntax. But often we have different constructor parameters. Or how about initializing using a factory method, like ExampleClass exampleObject = ExampleBuilder.CreateExample();? Your syntax doesn't save us anything there, whereas the type inference in var will allow us to use var exampleObject = ExampleBuilder.CreateExample(); smoothly.

Related Solutions

C Syntax – Design Choices for Arrays, Pointers, and Functions

My understanding of the history of it is that it's based on two main points...

Firstly, the language authors preferred to make the syntax variable-centric rather than type-centric. That is, they wanted a programmer to look at the declaration and think "if I write the expression *func(arg), that'll result in an int; if I write *arg[N] I'll have a float" rather than "func must be a pointer to a function taking this and returning that".

The C entry on Wikipedia claims that:

Ritchie's idea was to declare identifiers in contexts resembling their use: "declaration reflects use".

...citing p122 of K&R2 which, alas, I don't have to hand to find the extended quote for you.

Secondly it is actually really, really difficult to come up with a syntax for declaration that is consistent when you're dealing with arbitrary levels of indirection. Your example might work well for expressing the type you thought up off-the-bat there, but does it scale to a function taking a pointer to an array of those types, and returning some other hideous mess? (Maybe it does, but did you check? Can you prove it?).

Remember, part of C's success is due to the fact that compilers were written for many different platforms, and so it might have been better to ignore some degree of readability for the sake of making compilers easier to write.

Having said that, I'm not an expert in language grammar or compiler writing. But I know enough to know there's a lot to know ;)

C# Syntax – Is There a Reason to Prefer Lambda Syntax Even with One Parameter?

Looking at the compiled code through ILSpy, there actually is a difference in the two references. For a simplistic program like this:

namespace ScratchLambda
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Text;

    internal class Program
    {
        private static void Main(string[] args)
        {
            var list = Enumerable.Range(1, 10).ToList();
            ExplicitLambda(list);
            ImplicitLambda(list);
        }

        private static void ImplicitLambda(List<int> list)
        {
            list.ForEach(Console.WriteLine);
        }

        private static void ExplicitLambda(List<int> list)
        {
            list.ForEach(s => Console.WriteLine(s));
        }
    }
}

ILSpy decompiles it as:

using System;
using System.Collections.Generic;
using System.Linq;
namespace ScratchLambda
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            List<int> list = Enumerable.Range(1, 10).ToList<int>();
            Program.ExplicitLambda(list);
            Program.ImplicitLambda(list);
        }
        private static void ImplicitLambda(List<int> list)
        {
            list.ForEach(new Action<int>(Console.WriteLine));
        }
        private static void ExplicitLambda(List<int> list)
        {
            list.ForEach(delegate(int s)
            {
                Console.WriteLine(s);
            }
            );
        }
    }
}

If you look at the IL call stack for both, the Explicit implementation has a lot more calls (and creates a generated method):

.method private hidebysig static 
    void ExplicitLambda (
        class [mscorlib]System.Collections.Generic.List`1<int32> list
    ) cil managed 
{
    // Method begins at RVA 0x2093
    // Code size 36 (0x24)
    .maxstack 8

    IL_0000: ldarg.0
    IL_0001: ldsfld class [mscorlib]System.Action`1<int32> ScratchLambda.Program::'CS$<>9__CachedAnonymousMethodDelegate1'
    IL_0006: brtrue.s IL_0019

    IL_0008: ldnull
    IL_0009: ldftn void ScratchLambda.Program::'<ExplicitLambda>b__0'(int32)
    IL_000f: newobj instance void class [mscorlib]System.Action`1<int32>::.ctor(object, native int)
    IL_0014: stsfld class [mscorlib]System.Action`1<int32> ScratchLambda.Program::'CS$<>9__CachedAnonymousMethodDelegate1'

    IL_0019: ldsfld class [mscorlib]System.Action`1<int32> ScratchLambda.Program::'CS$<>9__CachedAnonymousMethodDelegate1'
    IL_001e: callvirt instance void class [mscorlib]System.Collections.Generic.List`1<int32>::ForEach(class [mscorlib]System.Action`1<!0>)
    IL_0023: ret
} // end of method Program::ExplicitLambda


.method private hidebysig static 
    void '<ExplicitLambda>b__0' (
        int32 s
    ) cil managed 
{
    .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = (
        01 00 00 00
    )
    // Method begins at RVA 0x208b
    // Code size 7 (0x7)
    .maxstack 8

    IL_0000: ldarg.0
    IL_0001: call void [mscorlib]System.Console::WriteLine(int32)
    IL_0006: ret
} // end of method Program::'<ExplicitLambda>b__0'

while the Implicit implementation is more concise:

.method private hidebysig static 
    void ImplicitLambda (
        class [mscorlib]System.Collections.Generic.List`1<int32> list
    ) cil managed 
{
    // Method begins at RVA 0x2077
    // Code size 19 (0x13)
    .maxstack 8

    IL_0000: ldarg.0
    IL_0001: ldnull
    IL_0002: ldftn void [mscorlib]System.Console::WriteLine(int32)
    IL_0008: newobj instance void class [mscorlib]System.Action`1<int32>::.ctor(object, native int)
    IL_000d: callvirt instance void class [mscorlib]System.Collections.Generic.List`1<int32>::ForEach(class [mscorlib]System.Action`1<!0>)
    IL_0012: ret
} // end of method Program::ImplicitLambda

Best Answer

Related Solutions

C Syntax – Design Choices for Arrays, Pointers, and Functions

C# Syntax – Is There a Reason to Prefer Lambda Syntax Even with One Parameter?

Related Topic