Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow shorthand/inferred assignment of class fields #20819

Closed
HakanL opened this issue Jul 12, 2017 · 1 comment
Closed

Allow shorthand/inferred assignment of class fields #20819

HakanL opened this issue Jul 12, 2017 · 1 comment
Labels
Area-Language Design Resolution-External The behavior lies outside the functionality covered by this repository

Comments

@HakanL
Copy link

HakanL commented Jul 12, 2017

I have a framework where I create "scenes" in C#, basically to describe a business process. I have these as classes and in them I define a bunch of fields to be used inside the class to operate on the business process (it's actually controlling DMX lights with the description of what should happen to the lights (the field variables) in the scene throughout the various class methods). So I have code like this:

public class MyScene
{
    AnalogInput3 masterVolume = new AnalogInput3(persistState: true, defaultValue: 1.0);
    Controller.Subroutine sub3dfxRandom = new Controller.Subroutine();

    public void Execute()
    {
        masterVolume.Set(0.5);
    }
}

My suggestion is to allow the use of var instead of having to have the class type in here twice, like we can do on stack variables, etc. So the code could be like this instead:

    var masterVolume = new AnalogInput3(persistState: true, defaultValue: 1.0);
    var sub3dfxRandom = new Controller.Subroutine();

Less typing, easier to read, less risk of error, and the compiler could easily infer the type.

Optionally it could also be used with readonly and access modifiers:

    readonly var masterVolume = new AnalogInput3(persistState: true, defaultValue: 1.0);
    private readonly var sub3dfxRandom = new Controller.Subroutine();

The goals of these classes (in my example) are to be as easy to read as possible (DSL), and allow the developer to focus on the functions of the scene with as little "plumbing" as possible.

@Joe4evr
Copy link

Joe4evr commented Jul 12, 2017

Dupe of #2114, #4423, #11551, and now tracked at dotnet/csharplang#601 (where language proposals should go).

@gafter gafter closed this as completed Sep 8, 2017
@gafter gafter added the Resolution-External The behavior lies outside the functionality covered by this repository label Sep 8, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Resolution-External The behavior lies outside the functionality covered by this repository
Projects
None yet
Development

No branches or pull requests

4 participants