About variables in programming

19 May, 2020

If you look at Wikipedia, you can see that a variable in programming is a named, or otherwise addressed, area of memory whose address can be used to access data. The word from this definition to which I would like to draw your attention is data. Is it really so that in the programming languages in which we write, variables are used only for accessing data. In fact, in addition to data access, variables are also used to access objects (instances of classes) and arrays (associative and ordinary) and some other things. Data (strings, integers, floating-point numbers, boolean values), objects (instances of classes), and structures for a human are essentially different entities (abstractions), and it would be reasonable to handle them as different things, ignoring the fact that for the machine they are the same (named memory areas). In order to do this, instead of variables, we can start to use such entities as, for example: object, structure, data. This will help to greatly simplify the perception of the code, because you no longer have to keep in mind the data types of most variables.

// If formerly, for example, to store objects in PHP, 
// we used variables that are declared in the current syntax using the $ symbol

$objectVar = new SomeClass();

// Now for the objects we will have a special entity “object”, 
// which, for example, will be declared using the * symbol

*objectEntity = new SomeClass();

// "Structure" entities will be declared using ^ symbol

^simpleArray = ['one', 'two', 'three'];
^associativeArray = ['key' => 'val', 'another_key' => 'another_val'];

// And "data" entities using symbol %

%string = 'abcde';
%integer = 123;
%floating = 1.23;
%boolean = true;
I want to make one point right away - my concept has nothing to do with the concept that is used in the PERL programming language, where each data type has a separate character. I urge only to enter one symbol for all scalar types, one symbol for objects and one for structures (arrays). The variables themselves and the symbol that is used to denote them ($) can be left for backward compatibility, as well as for types that are not covered by the new entities described by me, one of such types, for example, resource. Also, not to mention that in order to implement the innovations described by my concept, one will have to sacrifice some types conversions, for example, neither data, nor objects, nor structures can be converted to each other as they are presented now. But the loss here is not great, since the need for such conversions in practice is almost absent. Really important conversions of scalar types among themselves will remain unchanged. Consversions that are required by the context, that is, those that only return the changed value, but do not change the value stored in entity will remain unchanged. For example:

function foo(bool %dataEntity, array ^structureEntity)
    var_dump(%dataEntity, ^structureEntity);

*object = new SomeClass();
*anotherObject = new AnotherClass();

// Will work and output information about boolean type  and array
foo(*object, *anotherObject);
In conclusion, I will say that I do not see any obstacles before adding my concept to other programming languages.