Minor nitpick: A symbol isn't necessarily a string. In fact, it
could be a
number, and you could have symbolic references based on numbers *as
symbols*...the numbers may or may not be...consecutive: just because
there's a
data location associated with 1, 3, 4 and 5 doesn't mean there's any
data
location associated with 2.
Just like BASIC line numbers as used
in the 70s/80s (and probably 60s - I didn't do any programming then) are the
identifying symbols of the destinations of GOTOs, GOSUBs and RESTOREs.[ Reply to This | Parent | # ]
|
In the implementation of most programming languages, for example C/C++, a
"symbol" is a string which names something (a class, variable, function, method,
etc.). They are stored in a symbol table, and they are all strings (not
necessarily alphanumeric strings though, symbols might include some unusual
characters--especially "mangled" symbols, which encode type information using
characters the programmer isn't normally allowed to use when naming things).
The symbols used in Java and talked about in this case, are similar to C/C++
symbols (they are a string that names something).
In Java, "symbolic
references" always involve qualified names (of the "package.class.field" sort)
or parts of a qualified name. Thats why the "symbols" talked about in the VM
spec, and in this trial, are always strings.
It's not quite the same as the
mathematical meaning of "symbol" (which is an abstract thing that could
represent anything... a number, an idea, a placeholder, or anything else).
Computation is a mathematical process, which involves manipulating these
mathematical "symbols". But that's something else, not to be confused with the
kind of "symbols" at issue in this case (which are strings that name something). [ Reply to This | Parent | # ]
|