Links

Categories

Tags


« | Main | »

Let’s talk ‘private’

By Jewe | January 4, 2015

About making class members private, why I didn’t want to support it, and why I finally added it.

Yesterday I committed the first bunch of changes to support declaring a member variable or member function private. It already works, but there still may be some cases where the compiler doesn’t notice that you have no access to a variable or function. This will improve over time.

Only a scripting language

It was always my opinion that a scripting language should not require as much knowledge and skill as a high-level programming language. I have nothing against trying to make JewelScript the most powerful scripting language in the world, but I do want to try to keep it simple and easy to use at the same time. Thus, my goal was to avoid the overbearing complexities that tend to come with high-level languages.

Restricting access to class members was my final frontier — the point where I mentally drew the line. I was convinced if you needed that level of complexity, you probably should be using a high-level language, not a scripting language.

On the other hand, object-oriented programming languages have been around for a few decades by now. Since the advent of C++ and especially Java, object-oriented programming paradigms have found their way into the heads of a lot of people, even some who aren’t hardcore programmers.

That’s why I decided that adding single inheritance to JewelScript would be too important a feature to give up — even if it introduces another level of complexity to the language that most script programmers probably won’t need.

I have toyed around with JewelScript’s single- and multiple inheritance for a few days now, and even ported some of my more complex script applications to these new features. It works pretty well by now and makes the code a lot simpler and cleaner. If your script application gets that complex, I guess being able to inherit and override is a blessing, not a curse.

There’s one consequence coming from JewelScript’s inheritance that I already foresee though: It’s easier to create duplicate variable or function names now. And this is where the new private keyword comes in.

Solving duplicate symbol problems

When you extend a base class, and especially if you use multiple inheritance, chances increase that a base has a function or variable that another base has already defined. Now I don’t want to add the complex mechanisms that allow C++ to handle such ambiguous situations. However, I wondered what I could do to help decrease the chances of compile-time errors due to duplicate symbols. So I decided to add ‘private’ to the language after all.

At present you can only make methods or member variables private. Not static functions, constants or type names. And I think that’s enough for the purpose I intended. If your base class makes a variable or method private, then you may use that variable or method name in your new class again. It will be a new variable or method that is unrelated to the old one.

class A
{
    method A(int i)
    {
        V = i;
    }
    method Print()
    {
        println(V);
    }
    private int V;
}

class B extends A
{
    method B(int i) extends A(i)
    {
        V = i * i;
    }
    method Print()
    {
        println(V);     // print B::V
        base.Print();   // print A::V
    }
    private int V;
}

function main()
{
    B b = new B(69);
    b.Print(); // prints 4761 and 69
}

Topics: docs, news | Comments Off on Let’s talk ‘private’

Comments are closed.