Chapter 1: Core Concepts

These are the concepts that are most basic to the ColdC language and/or ColdCore. Expect to find articles about how the systems deals with objects, how code interacts with variables, or the meaning of encapsulation (okay, those were all related topics -- but that's exactly why they need to be explained).

Encapsulation

Summary

Encapsulation is the technique by which ColdC carries out the programming concept of Information Hiding, and thereby, Separation of Concerns (advanced programming concepts which I'll only touch on here).

The basic breakdown:

  • Every object has its own information (object variables)
  • Nobody else can see or use its information (in that no other objects may access another object's information)
  • The only code (method) that can access an object's information is its own code -- code that is defined on that same object

Simple enough rules: my info is mine, your info is yours, and we don't share! However, eventually the objects will need to exchange their information with eachother, and possibly change each other's information depending on the scenario. Each object can, however, have public methods, which are usable by other objects.

Object Example

Let us say we have two objects: $picnic_table and $garden_hose. Let us also say that the table can be wet (or dry), and the hose can make things wet.

$picnic_table variables:

wetness
How wet the table is (0 to 100%)

$garden_hose variables:

wetness_per_second
How much wetness the hose adds per second

Let us say we wish to program the hose to automatically spray the table until it is 100% wet (I know... weird example). The code to spray water will be defined on the garden hose, but as we know, code on the garden hose cannot modify the wetness variable found on the table. Instead, the table must also have a method that will allow it to be made wet. In addition, the hose will need to know how wet the table is, so the table will also need to have a method which will reveal the wetness of the table.

$picnic_table methods:

@program $picnic_table.add_wetness +access=public
	arg howMuch;
	wetness += howMuch;
.

@program $picnic_table.get_wetness +access=public
	return wetness;
.

$garden_hose methods:

@program $garden_hose.spray +access=public +flags=forked
	arg target;
	
	while (target.get_wetness() < 100) {
		target.add_wetness(wetness_per_second);
		$scheduler.sleep(1);
	}
.

In this manner, code from one object may interact indirectly with the data stored on another object. The power of this approach to programming is realized when you consider that the hose does not care what it is spraying -- as long as the target knows how to get wet. Likewise, many things can make the table wet -- the table doesn't care how, as long as the .add_wetness() method is called. This concept is a type of Polymorphism.

Inheritance

Summary

One of the greatest strengths of an object-oriented programming environment is the power of inheritance. Every object in Cold has a "parent," or an object on which it was based on. The new object is then said to be the "child" of the "parent." Inheritence, simply put, is the idea that the child will inherit certain traits and behaviors from the parent.

Variable Inheritence

Summary

Cold objects inherit the functionality of their parents, but not all of the properties. Keep in mind that an object variable may only be read or written by methods defined on the exact same object that the variable is defined. This means that code defined on descendants may not directly access variables defined on ancestors.

Example

Let's create a $thing named Test1, then create a child of Test1 named Test2. We will define a variable on Test1 called var_test, then we will define a method on Test2 called get_var_test, which will attempt to read Test2's var_test value.

@new $thing named Test1
@rename Test1 to $test1

@av $test1,var_test = 1

@new $test1 named Test2
@rename Test2 to $test2

@program $test2.get_var_test +access=public
	return var_test;
.

If you follow the above example, you will find yourself with an error when you attempt to execute Test2.get_var_test():

;$test2.get_var_test()

However, if we instead define the verb on the same object that var_test was defined on ($test1), then we'll see that this works better... and can also be used effectively on $test2, since it will inherit the behavior of $test1.

@dm $test2.get_var_test

@program $test1.get_var_test +access=public
	return var_test;
.

Now try to execute .get_var_test() on both $test1 and $test2...

;$test1.get_var_test();
;$test2.get_var_test();

You will see that both calls executed properly -- until you look more closely at the values that were returned. The first call (on the parent) returned the value that you set when you created the variable... but the call on the child, $test2, returned 0. This is because object variable values are encapsulated across generations. The value of the parent will not be inherited by the next generation, nor vice versa.