How to explain the difference between a variable and a key in a key-value pair

conceptslanguage-agnostic

Variables and the keys in key-value pairs are both identifiers for values, so, on a conceptual level, these seem very similar ideas.

How would you explain the difference between these two concepts?

Is it that key-value pairs are used in collections?
Is it that variables point to a memory location?
Or something else?

(If I look at code, I'm instinctively aware of the difference, the question's more about how to explain it which doesn't seem too obvious given that they do similar things.)

Best Answer

There is no real difference.

We can think of a variable as a name that maps to some value. All visible variables together make up the environment. This observation is important in some theoretical discussions, and is also used in some language implementations (mostly dynamic languages like Ruby). Especially objects can be represented in different ways – some may be choose static structs where an object member is a field in that struct (e.g. C++), others may use dynamic dictionaries which contain all members as key-value pairs (e.g. JavaScript).

The nice thing is that these are mostly equivalent to each other: you can see one as a generalization, the other as a performance optimization.

In sane languages, the environment is known at compile time, whereas the keys in some dictionary are generally only known at run time. This is the only useful difference: when the key of some mapping is known.

Related Solutions

Type Systems – Difference Between Casting and Converting Types in Imperative Languages

Theoretically speaking, the two concepts are vastly different:

Type Casting refers to exchanging one type (roughly speaking, an object structure) for another while Type Conversion refers to translating of values (roughly speaking, contents of the object), so that they may be interpreted as belonging to a new type. Theoretically, they never mix.

That said, practically speaking, while you can have one without another, it's, almost always, a bad idea. It rarely makes sense to change your perception of an objects' structure, without also altering its contents. Practically, they're almost always the same

Immutability – Differences Between Immutable Value Types and Reference Types

You are defining value types and reference in a language agnostic way, but doing so only by example in terms of changing of data members. Logically, making the types immutable makes you lose the only difference guaranteed by your definition (and the answer might be "no").

However, once we start looking at particular programming languages, then yes: there are more differences.

Consider the following C# example.

void increment()
{
    lock (synchro)
    {
        total++;
    }
}

private int total = 0;
private SomeType synchro;

If SomeType is a reference type, this counter will be thread safe. If SomeType is a value type, then, due to boxing, each thread is locking a copy of synchro and increments may be lost under concurrency.

Of course, there are no genuine immutable types in .NET in the most abstract sense, as the monitors involved are implemented using hidden fields (akin to the C++ mutable keyword that can declare mutable members in otherwise immutable types). But on Stack Overflow, everyone will understand your question to refer to anything that their platform calls "immutable".

Best Answer

Related Solutions

Type Systems – Difference Between Casting and Converting Types in Imperative Languages

Immutability – Differences Between Immutable Value Types and Reference Types

Related Topic