Ecere Blogging

Today I want to talk to you about eC properties, as well as conversions properties which reveal their true power… As you may know, eC places a lot of emphasis on properties. Properties are sort of half-way between methods and data members. They provide methods to “set” or “get” the property of an object, which is often stored internally in a data member. eC has one of the cleanest syntax for defining properties:

class Pen
{
   Color color;
   public property Color color
   {
      get { return color; }
      set { color = value; }
   }
}

In eC, class constructors never take in any parameters. Instead, eC relies on the initializers passed through instantiation. These can either be data members or properties. Here is how one could set the color property for a Pen object:

Pen pen { red };
Pen pen { color = red };

Although functionally equivalent to Set and Get methods, properties behave exactly like data members (with some limitations, such as not being able to obtain their address). For example,

pen.color = ~pen.color;
pen.color += 10;
pen.color.r = 255;
pen.color = 0xFF0000;
pen.color = { 255, 0, 0 };

These all go through the Set/Get methods to do their work. Notice here that the Color class is an eC Bit Class, which allows to be accessed both as a “unit type”, such as setting it to 0xFF0000, and as a “structure type”, when accessing the r member or using the curly brackets initializers.

The advantages of properties are multiple. First, they allow for instant visual feedback, for example in the case of the Ecere IDE’s Object Designer. The IDE has a property sheet in which you can visualize and change the values of properties, and get instant feedback in the visual designer window. The IDE’s Object Designer is extremely powerful and versatile. Currently, it is only used for the Form Designer, which is itself bundled inside the Window class of the runtime library. However, third parties could easily integrate into it to enable to visually represent and edit their own classes. The property editor as well as the code generation & parsing system will automatically be usable to those ends. This system all relies on the properties and was the original reason for designing eC and the Ecere Component Object Model.

Second, properties present this layer of protection over the data members. A property can be made public whereas the data member actually used to store the property can remain private. Properties can also only contain a Set or a Get method, therefore making it write-only or read-only. A property can also return or set a value which is not stored exactly as such in the class. This brings us to a special case of eC properties, the Conversion Properties.

Conversion properties are specified with only a data type, and no “name”. For example, a Radians property in the Degrees class allows to set a Radians value to a Degrees angle. eC will resolve cascading conversions to convert from one type to another. This is what enables the following magic:

pen.color = ColorHSV { 0, 100, 100 };
pen.color = ColorLab { 53, 79, 66 };
pen.color = ColorCMYK { 0, 100, 100, 0 };

Beautiful isn’t it? But what is really wonderful is that all this is done at compile time. Therefore this is not any slower than providing the color in RGB format, as the eC compiler will do all conversions and store the proper hexadecimal value here for the color. Like most class constructs, properties (including conversions) can be used in any kind of eC data types (structs, classes, units, enums…). However, they play a major role in the Units, to establish the relation between different compatible units, often allowing to perform the same functionality as overloaded operators would in other languages such as C++. It is therefore a very powerful tool which can save considerable amounts of code, since you don’t need to provide the implementation for any operator.

Here is an early implementation of a dynamic array for Ecere…

It is most likely a interim solution until truer “templates” make an apparition in eC.

Download Array.ec

(Please don’t mind the obscurity of the internals. Like all things, it’s impermanent.)

You would use it as such:

import “Array”

public class ArrayPoint : Array
{
type = class(Point);
public Point * points;
};
void Test()
{
ArrayPoint points { size = 10 };
points.points[0] = { 10, 10 };
points.size = 20;
points.points[19] = { 5, 5 };
delete points;
}