Data: that's another word for information.  But what is a data type?  And why should you care?

 

Objects and Types

 

For several decades, programmers have been developing software based on the concept of objects.  Put simply, an object is something that has characteristics and can do things.  For example, a car is a kind of object: a typical car has an engine capacity and a colour.  It also starts when the ignition is turned on.  In reality, cars – indeed, any types of object – have all sorts of characteristics and behaviours but we will usually only be interested in a few of them.  In the world of Absyntax, an object is an item of data.

 

Programmers define types.  A type is like a template: it's a complete definition of the characteristics and behaviours that all of its objects are to support.  Thus when we have an object of type "Car", we know that we will be able to find out its engine capacity and its colour, and we also know that we can make it "start" (whatever that might mean).  Absyntax features define their data inputs and data outputs in terms of the types of data they support.  Thus if a particular input has a data type of “Car" then it will only accept items of data that are cars.

 

Object Composition

 

Let's take this a step further.  Engine capacity is probably most usefully expressed as a whole number of cubic centimetres.  But in the world of software, a whole number is also a type of object.  And what about colour?  Perhaps text could be used to describe a car's colour, but one man's "purple" might be another man's "indigo".  So perhaps colour would be best defined in terms of its RGB content.  In other words, we could define a type called "Colour" with the characteristics "R(ed)", "G(reen)" and "B(lue)", each of which could be a whole number in the range 0 to 255.  In which case "indigo" could be represented using values for R, G and B of 75, 0 and 130 respectively.

 

What has just been described is object composition.  It means that objects can be expressed in terms of other objects.  A car, for example, can be expressed in terms of a number (engine capacity) and a colour.  In turn, colours can be expressed in terms of three numbers.  This is useful to know because it will help you to:

 

 

It is also useful to understand inheritance because this will help you to understand type conversion.  Consider that the "Car" type might have characteristics in common with other types.  Hair dryers, for example, also have colour and can be "started".  That said, they don't normally have engine capacities.  Programmers often recognise such scenarios as this and define their templates accordingly.  Both the "Car" type and the "HairDryer" type share some details, and so a programmer might define a type named "PoweredItem", which supports a colour and can be started.  So, if the "Car" type is defined as being a type of "PoweredItem" then it needs only to define engine capacity as an additional characteristic because it inherits the characteristics of its parent type.  This means that, say, a data input supporting "PoweredItem" types will accept both items of type "Car" and items of type "HairDryer".

 

Namespaces

 

Commonly, the name assigned to a type is qualified by a namespace.  An example is "MI2.Units.Lengths.Metre", which includes the namespace ("MI2.Units.Lengths") and the type name ("Metre").  A namespace is a naming convenience used by type designers for the purpose of organising types within a software library or application.  The Absyntax Editor displays namespace-qualified type names in several places but is generally of academic interest to Absyntax users and mentioned here for information only.