Bart said:
The value of a variable is traditionally undefined before it gets a
value (undefined in the literal semantic sense).
Again you are being vague about what you mean by a variable. In C, for
example, a subroutine local variable is a fixed size lump of space on
the stack. It is referenced relative to (offset from) the stack pointer
and while a name might stand in for that reference in the source code
that does not mean the concept and mechanism maps well to javascript.
In javascript the variables are named properties of objects, and all
properties of objects have values.
I'm not sure how that works on js compile level, but it is a principle
of which you can't step away:
But is it a principle that applies at the level that javascript
operates at?
var x = 'abc'
is one instruction, but is short for
var x
x = 'abc'
First create name x and then give it the value 'abc'.
In javascript the "first create name x" stage is "first create a
property of the Variable object and assign it the Undefined value".
As long as 'abc' is not assigned, x remains undefined,
In javascript - x - retains its undefined value.
that is, no value is associated with the declared name at that point.
Which is precisely not the case in javascript, where the general fact
that no property of an object can exist without having a value requires
that variables have values from the moment of their creation.
I try to avoid analogies, but first you need to have a box before
you can put something in it (you
need to have something to put 'abc' in).
But simultaneously, as soon as you have a box it has something in it
(if only a vacuum (as the most 'not containing anything' that a
container can achieved)).
Before you instruct what's in the box, nothing is said about what's
gonna be in it, but the box must exist already. At that stage, the
contents of the box is (still) undefined.
Going back to reserving space on the stack, it would be possible for a
complier to do either of, zeroing all the bits in the reserved space or
leaving it as it is. In both cases the 'variable' would have a 'value'
(in some sense) prior to any explicit assignment of a value.
(1) reserve the name (declaration) [*]
There is no reserving of names in javascript. The properties of objects
that represent variables are created during "variable instantiation".
Reserving a name is a very simple thought. Every javascript variable
has a name. The programmer reserves a name in order to reference
to it at a later time. The official term is "declaration".
Maybe, but the mechanism is the creation of a named property of an
object at a particular point in the execution of the code.
Indeed, that is technically not important as long as your scope is to
stay working inside the javascript engine. But the broader concept is
very important in a sense that every computer works that way.
But when you are talking about something that represents a named
property of an object having an internal attribute that links it (in
some way) to a manifestation of a value, and none of: the nature of the
property, the nature of the value, nor the linking between the two, are
specified beyond the behaviour of the resulting system that is to be
achieved, talking of bit patters is meaninglessly specific (even if the
nature of a computer implies that bit patterns must be being set
somewhere).
The memory is traditionally freed once the bytes that hold the value
are made available again for other instructions.
The implication of the way you worded that was that "free up the
memory" referred to the memory for the variable. But as the variable is
a property of an object the memory needed for the variable itself
cannot be freed until the value of the object that holds the property
is freed.
Say I have 4 bytes to
my disposal on a 7-bit computer, and do
x = 84
then I take one of the 4 bytes and put 0101010 in it, with 1 as closed
circuit ("on") and 0 as broken circuit ("off"). At that point, x holds
a value and I'm using 25% CPU of the 4 available bytes. When I assign
an empty string to x, I just set it to 0000000,
I suspected that your concept of an empty string was a NULL (zero byte
in this context) terminated sequence of bytes (or maybe 16 bit words).
In Java, for example, a string is an object and so 'assigning' even an
empty string may mean writing a 32 bit memory address into your 4
bytes.
but I'm still using 25% CPU. Then I make x undefined, thus disconnecting
the byte from x. Then I'm again at 0% CPU (4 bytes available again).
Again you have a concept that is certainly above machine code (where
bytes being 'available' or 'unavailable' is not externally imposed),
but at the same time a concept that is below (or not sufficient to
explain) Java.
I'm not saying this applies to javascript;
There is very little that can usefully be said about javascript that
can be expressed in terms of writing values into specific memory
locations. Javascript is just too abstracted from that level.
but it might be worth testing it.
Testing what precisely?
With very large strings, such memory fluctuations might(!)
be measurable in the browser,
They are.
but I'm afraid of caching mechanisms +
all kinds of intermediate levels.
[...]
Probably I'm thinking in too classic theoretic patterns.
Or maybe you are trying to apply a theory to the wrong structures.
That is possible.
[*] Maybe javascript's "var myvar;" syntax is a far heir of that.
That does not make sense to me.
When you say "var myvar = 'abc'", you pass 2 commands, namely "var
myvar" and "myvar = 'abc'".
I cannot see any way of interpreting your first statement that results
in the second.
Richard.
:-(