The leap from a procedural language to an object oriented language is huge for both the designer (me) and the user. I have established the guidelines and practises how CoolBasic programs need to be built, and I’m already seeing light at the end of the tunnel (which doesn’t, however, mean that I’m nearing the end). From the user’s point of view the change is so big that CoolBasic V3 can be considered completely different a language from what it used to be. And it is. You are going to be writing slightly more code to achieve same results compared to the current CoolBasic (that never got past its Beta stage haha).

In OOP languages, all executing code must be written inside a procedure. I say procedure, because it’s a uniting term for Functions, Properties and Operators. This means that the main loop of a game must also be inside a Function. Since functions can only appear within the module context, you must define the containing module or class. You can’t call the starting code from outside, so the concept of Main Function needed to be implemented. What this means, is that you must always write Function Main() somewhere in your root level Modules. It operates as an entry point to your application. Only one Main Function can be defined. The concept is similar to .NET languages and C/C++.

It may seem like much, but in the end it isn’t. Sure you have to build all programs in a certain way based on a skeleton, but after that things get simplier. The following code demonstrates a simple HelloWorld program. It will require 11 lines of code whereas the old CoolBasic only required four lines. But you really can’t simplify things any more than that in the OOP world. This can be confusing to newcomer programmers, so perhaps when you create a new project in the CoolBasic code editor, this skeleton could be automatically typed in – for reference and easy start.

Simple HelloWorld Example

Please note that the example program above is subject to change, and is most likely not final. Most of the example’s code lines belong to the frame you need to define. The main loop is still quite simple. First we open a windowed game screen of 800×600 dimensions. Then we loop two lines of code (text drawing and screen updating) until the Screen is closed. The biggest challenge is to memorize all new classes and their methods. A brand new, comprehensive and user-friendly manual will help with this, and perhaps I’ll implement some kind of an intellisense-prompt to the editor at some point.

A short update on CoolBasic V3 compiler progress: The above example fully passes the lexer, and soon the parser (Pass#1) aswell. All in all, I need to implement the parsers in the same order as one would write code to a program; containers first and then the statements. It’s slow in the beginning due to the complex structure of, say, Function statements and such, but the rate should accelerate when I progress through the simplier statements in the end. I recently finished the Function statement parser which is one of the largest and most complicated parsers, and I feel good about it; solid ground is the key to success. I expect to implement the Class and Interface parsers in the near future.

As a new feature, CoolBasic V3 will support class properties. You may have already seen a hint for property support when I discussed about the String implementation earlier in this blog. Properties work just like any other Public variable, i.e you can access then by using the dot notation, but with a added twist. Normally, when you either assign or read a value from a Public variable nothing else will happen. But with properties you are able to capture this event, and execute your custom code to get the job done. Basically, we’re talking about old-fashioned way of creating getter and setter -functions. Without properties you’d have to write these two functions in order to access, say Private variables:

MyClass.SetName("hello")
Console.WriteLine(MyClass.GetName())

With properties you could do the same in more decent way:

MyClass.Name = "hello"
Console.WriteLine(MyClass.Name)

You still define the getting and setting code within the property structure, but done so they’re unaccessible from outside. So you have nice little black box of which workings not even the class members know about. There’s a difference in using the property name than assigning the value to the private variable in question by hand – even when all the setter does is the assign. There’s always code involved when accessing property values.

In addition you can define the property as ReadOnly or WriteOnly. By doing this, you protect some data that must not be modifier from outside. One example of a ReadOnly property would be the length of a string. The property returns the value of a Private variable, however this information is related to the actual data within the String class, and should only be updated when this inner data changes. It’s the only way of keeping such information in sync in a secure way. Now if you come to think about it, constants are ReadOnly, too (except that CoolBasic compiler doesn’t work like .NET compilers in this regard).

Since properties are really a set of methods, they can be inherited. This also means that things like overriding, are possible. However, at this point in time, I’m still a bit unsure about one thing called Default property. A property can be defined as Default when you access the object without providing further dot notation. Sound like normal object reference? Well, there’s a catch. In VB.NET Default properties always need atleast one parameter which means you must include a set of brackets to it. A typical example would be the myVar.Item(index) property you could refer to just myVar(index). I don’t like this because it’s easy to mix this to a method call.

On the other hand, I would still have to allow parameters for properties because it’s the only way to implement indexes to them. Like above. If I ever wanted to implement LinkedLists or Lists or any variant, I, in fact, must allow this. There are still lots of questions floating I need to chew on.

Warning, wall of text incoming!

“In computer programming, scope is an enclosing context where values and expressions are associated. The type of scope determines what kind of entities it can contain and how it affects them. Typically, scope is used to define the visibility and reach of information hiding.”

The scope of an entity’s name is the set of all declaration spaces within which it’s possible to refer to that name without qualification. In general, the scope of an entity’s name is its entire declaration context; however, an entity’s declaration may contain nested declarations of entities with the same name. In that case, the nested entity shadows, or hides, the outer entity, and access to the shadowed entity is only possible through qualification.

So much for theory (the quoted text was from Wikipedia). Now, what does that mean for CoolBasic…

In VB.NET and C# there are mainly two kinds of scopes: We have a root/namespace/class/structure context, and then we have a method/block context. The main difference between the two is how data can be referenced in Object Oriented Programming. Class instance variables (objects) store their values in heap because they are reference types and their life span is not determined beforehand by the compiler. Procedure variables, however, store their values in stack. It’s a static space in memory where procedure variables temportarily reside, but from which the space is automatically freed when the life span of all those variables ends, i.e the procedure exits. Because of the stack, recursive calls are possible.

It’s important to realize that the program structure is highly hierarchical in Object Oriented Programming. It’s all about references to other objects and their parent-child relationship. Gone are the days of procedural programming and direct function calls where the only way to share data between two functions, was to introduce a global variable to hold that data. Now, global variables are quite bad a concept and frowned upon by most programmers today. That’s because in general, it’s often difficult to keep track of the value of a global variable plus all entities that can modify it. In the end, there’s more cons than pros when we’re dealing with large and complex projects.

I will not talk about global variables (or the lack thereof) just yet. Nor will I define concepts of Inheritance, Shadowing or Overriding because in all probability I’m going to do so at some point in future anyway. For quick reference, “inheritance” means reference-based access to a parent class from a derived class. “Shadowing” means identifier matching to the nearest level upwards within the program tree. “Overriding” means priority of methods, operators and properties through inheritance for identifiers with matching signature. “Implementing” means copying functinalities from an interface-template.

In VB.NET and C# there are some restrictions what you can and can’t declare within each type of entity. The basic concept is that all code is written inside a class. The only exception would be the root context which itself behaves like a class. However, root level should have the main object created as soon as possible so the program can be redirected to true class-based execution. Classes can have methods (functions), operators (kind-of functions, but executed as operator instead of value), properties (a public attribute with functional purpose) and even inner classes. In addition, there can be structures (similar to classes), enums, constants, and attributes (variables). I’ll describe some restrictions that were mentioned in the MSDN documentation, but were never explained or justified why you can’t do these things. I had to figure these out myself, and there might still be some caps behind my logic. However, trying to understand the problem by oneself tends to be quite an enriching and valuable experience.

A function cannot be declared within the Block or Method context
A Block context does not have an identifying name that you could use to access it by using the dot notation. This itself is logically wrong. In addition, the member access operator (dot) only works with references, and neither block nor function is a reference. This means that functions don’t get unique memory addresses that are visible to the programmer. Even if you had a pointer to the function, it’d be still pointing to the code entry point and not to the actual member variables. Function members can never be Public. They can’t be Protected either, because functions cannot inherit from other functions. So function members are Private which means you couldn’t access them from the outside anyways. Function variables and their memory addresses will be determined during runtime because they reside in Stack. This offset can’t be calculated at compiling time. References, in the other hand, point directly to member variable addresses so the reference is always direct and valid.

This, however, doesn’t explain why the compiler couldn’t just enforce Private functions within the Block/Method context (all identifiers are local in these context levels). Firstly, there’s the logical issue: Why on earth would anyone want to defined private functions inside other functions. It’s like restricting yourself from data you’re eligible to use anyways – for no gain. Secondly, there’s the technical issue. While I *could* allow this kind of declaration in CoolBasic (even though it’s forbidden in .NET-languages), I think that it would be better for the compiler’s sake to prevent from mixing two separate scope definitors. Private/Public/Protected are intended to define reference context accessibility, the inheritance thing. Whereas keyword Dim is meant to define identifiers within nested local scopes. There’s no equivalece to Public in Method/Block context (if there was, you’d be able to call conditional code from outside, which could potentially break the program flow integrity), as explained above.

So let’s just assume that we have a function inside a local scope (another function or a block) with no separate access modifier in the declaration. The declaration is now legal as long as there are no inheritance-related modifiers or flags. We call this inner function only from inside of the hosting scope. What’s wrong with this? Well… nothing really, besides the odd visibility and reach. Can we implement this? Probably. Should we allow this? I don’t know. It just happens that when you enter a method scope you can, in fact, declare an identically named inner function. In this case, which function does a recursive call direct to? In normal rules of shadowing, it would be the same scope of the calling code unless qualified with Me or MyBase. The problem is, these two variables always refer to a class so you can’t point to the inner function. Either you use Me.myFunc() for the outer function or just myFunc() for the inner function. Also, it matters whether you make the recursive call from inside the inner function or from outside of it. Add different function signatures and you have a nice soup of failure.

As what comes to declaring classes within functions, the same rules kind of apply. You can’t use function name as parth of the dot notation, to point to a class or nested function. Even though the issue would not be reference-based at runtime (procedures get their fixed location within ASM at compiling time). It’s about the syntax and whether or not it’s allowed to do inconsistent/logically wrong things. Function references within the source code should always contain a set of brackets – which itself satisfies the member access operator (dot) because such a token will be identified as value evaluation.

A structure or enum cannot be declared within the Block or Method context
First of all, being unable to declare structures within procedures, but still being able to do so outside (which the function could use), made no sence to be. There shouldn’t be any restrictions becasue you can declare variables normally. Only so that the new structure/enum would be visible locally within the method scope. Some rules that were explained above still apply, but I think I have come up with a better explanation. Picture this: You have a structure called “myStruct” within a class context. Then you have a method that takes a typed variable (myStruct) in as a parameter. Because the scope has now changed, you can declare another structure that has the same name within the method. When the source code gets parsed for the first time, all identifier definitions are scanned. While it wouldn’t normally matter where you have the structures defined and still being able to use them from anywhere within its scope, it just happens that variables are identifiers, too. So they get scanned in the same way. You *could* do multiple passes for the source code to scan in layers, but in OOP this can be a bit problematic and slow. So in this scenario, you can define a variable as “myStruct” before and after the inner Structure is declared. Which means we have two different types for those variables even though they were typed using the same name. Confusing, eh?

Conclusion
When you think about it, the answer to all these problems could be the simplest one: They don’t want you to write structural definitions (such as structures, enums, functions or classes) to a code block which has executable code part (and thus no no declaration part that is separate). The basic priciple is that everything belong to their little boxes, and only access modifiers, inheritance and shadowing rule out information hiding and reach because they work in both ways in the program hierarchy. I think there’s enough reason already to conclude this think-tank into following the rules the wise guys at Microsoft have agreed upon, and not to allow nested functions in CoolBasic V3.