A programming language pattern idea.

July 21, 2005

How many times have you seen somebodys code that acts like following:

public class ClassA
{
    private string _myPropertyContainer;

    public string MyProperty {
        get { return _myPropertyContainer; }
        set {
            doSomething1();
            _myPropertyContainer = value;
        }
    }
}

I guess it was at least more than a couple of times, including the code of your own. And if you ask the programmer: “Why did you choose to access (or even worse, modify) private member instead of property?” — his answer with 99.99% probability will be “I don’t want the code inside the property getter or setter to be involved here. I just want to access/change the private member value.” And if you ask “Don’t you think this is a symptom of bad design”, you’ll get an answer “Not at all, the overall design is perfect, only this one little thing does not suit into it. It’s ok.”
Thus, everybody understand this is one of the worst thing you can do to your code, but everybody continue doing it. Why do you think people do this? No, this is not because they are bad designers. No this is not because they don’t think that writing error-prone and maintainable code is no important. People do this because they can do.
Yes, I meant that. People write code as bad as language and compiler permit them. If the compiler was able to restrict the access to private member _myPropertyContainer from the Method method, the programmer was investigating more time in design and was creating more clean code.
You may think I’m stupid. What does it mean “have no access to private members”? There is no such a thing! Yes, you’re right. There is no such a thing. But I want it.
Let’s illustrate my basic idea:

public class ClassA
{
    public void ClassA(string s) {
        MyProperty.container = s;
    }    

    public string MyProperty {
     get { return container; }
     set {
           doSomething1();
           container = value;
        }
    }
}

What does this piece of code changes? Note the private member _myPropertyContainer declaration has moved into MyProperty declaration. And I want that from now on _myPropertyContainer will not be visible for any class members except MyProperty.get and MyProperty.set. That is, if someone tries to access _myPropertyContainer from doSomething(), he will receive a compilation error. Thus a feature proposed will prevent a programmer from making a stupid mistakes by accessing a private member instead of the property.
Now lets take look on the paradigm proposed. First, if we want all of our properties to define a private member, we do not need to define this members at all — let compiler to perform this task instead of us.

public class ClassA
{
    public string MyProperty {
        get { return container; }
        set {
            doSomething1();
            container = value;
        }
    }
}

The piece of code above illustrates this approach: if you want to save a value as a private property member, you can use a special value container which corresponds to it. Of course, at the compile time each reference to this value is replaced by reference to actual property private member. If the container value never used inside property code, that means we have a read-only or calculated property. In this case compiler have no reason to generate private property member since it never used.
Sounds good? Yes, but not good enough. Sometimes you really need to access a private member, mostly in constructor when you want to initialize the property the the default value and any access to property set will change the object state (and, in general, the object is not fully initialized yet). So the second point is to enable an access to private property member from constructor, exactly as done for read only members.

public class ClassA
{
    public void ClassA(string s) {
        MyProperty.container = s;
    }
    public string MyProperty {
        get { return container; }
        set {
            doSomething1();
            container = value;
        }
    }
}

Now the picture is complete. MyProperty has a full access to its auto generated private member through container value. No one else from class members has an access to this property except constructor. Constructor accesses a private members by denoting them as MyProperty.container, so there is no ambiguity here.

Advertisements

3 Responses to “A programming language pattern idea.”

  1. anonymono Says:

    Sorry but I don’t understand this post at all.

    Firstly, this code doesn’t compile:

    public class ClassA {
    public string MyProperty {
    private string _myPropertyContainer;
    get {
    return _myPropertyContainer;
    }
    set {
    doSomething1();
    _myPropertyContainer = value;
    }
    }
    }

    Because in a property you can only have get/set (or add/remove in events) code blocks.

    And the rest code snippets don’t compile too, because you’re not declaring container variable :?


  2. You’re right, _myPropertyContainer should be declared inside the class but outside the property. Fixed, thanks.

    The rest of the code spippets can not be compiled just because this feature does not exist in the language (I hope it does’nt exist yet).


  3. […] was a pleasure to see that my old «A programming language pattern idea» hit straight to the […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: