Variables and arrays

[Winston Gutkowski]

Brian Tkatch wrote:Java may have its quirks, but they prove nothing.

It proves that an array is a type, not just a "chunk of memory"; and that each declared array type has an associated Class. Indeed, one of the first things beginners are taught is that, in Java, arrays are objects.
They even have a hierarchy - albeit a fairly shallow one, viz:

Object[] objectArray = new Object[0];
String[] stringArray = new String[0];

System.out.println(
   objectArray instanceof Object);   // prints "true"
System.out.println(
   objectArray instanceof Object[]); // prints "true" (obviously)
System.out.println(
   objectArray instanceof String[]); // prints "false"

System.out.println(
   stringArray instanceof Object);   // prints "true"
System.out.println(
   stringArray instanceof Object[]); // prints "true"
System.out.println(
   stringArray instanceof String[]); // prints "true"

The main point worthy of note being the second to last line: String[] IS-A Object[] - actually, all arrays are subtypes of Object[] (which is itself an Object).

Now it that doesn't convince you, nothing will.

Winston

[Brian Tkatch]

Winston Gutkowski wrote:
Now it that doesn't convince you, nothing will.

I guess nothing will. BTW, you can pretend this is related: wat

I understand that arrays are objects (though, a working understanding is beyond my current knowledge.) Regardless, that's an implementation detail. Arrays, in the theory, are not objects.

But, that's you for the demonstration, i appreciate it. Nothing makes a point better than code.

[Winston Gutkowski]

Brian Tkatch wrote:I understand that arrays are objects (though, a working understanding is beyond my current knowledge.) Regardless, that's an implementation detail...

Wat? Only as much as the keyword 'class' being used to define a template for an object is an "implementation". You better remember it if you want to use Java though, because it won't like 'ftang'.

Arrays, in the theory, are not objects.

What theory? And what planet did it come from?

Love the link though. Bookmarked.

Winston

[Brian Tkatch]

Winston Gutkowski wrote:What theory?

Let's learn about variables! (Or, at least, my view of them.)

Variables don't exist. They are simply (strictly typed) named memory locations used for convenience and to ward off errors due to mistaken use. Some languages allowed a problem to seep through by special handle handling that isn't always used, which can help illustrate the idea.

Regardless of how variables are typed (i.e. supported by the language), ultimately, the compiler (or runtime) knows what to expect in the memory location. That is, x bits or bytes are the desired datum. Indeed, on the x86 processor, the variable is (the equivalent of, or is) an offset in the data segment which denotes where the datum starts, and the variable type (or the datum itself) defines how "long" the datum will be. The retrieval is stopped when reaching the allotted space.

An array is different as we need two numbers. One, like before, how long each individual datum is, and two, how many of them there are. In some cases both numbers are recorded (where that is varies by language), in others, the array length is not recorded, but a stop byte is used (like C's string table where each string ends with a null byte.) Some, don't bother recording the length at all, and instead treat each individual array datum as a separate variable. So, the variable itself is actually an offset in the data segment, where the array offset (often, mistakenly called an index) if an offset from the start point. In either case, whether or not the length is stored, to retrieve an individual datum in the array, the offset is multiplied by the length of the type to find the starting point of the desired datum.

Hence, the actual use, or so the theory goes, is to treat each datum individually as if the array did not exist. The array is a mere convenience to group values together. Hence, the type itself never changes.

As it so happens, Java treats arrays as if they were objects. Ultimately, however, it makes no difference. It's just an implementation detail.

[Winston Gutkowski]

Brian Tkatch wrote:Might i ask this sub-thread be split from the rest (and then this remark removed)? IMO, it has nothing to do with it and does not belong in the current forum, though the original thread does.

Done.

Winston

[Winston Gutkowski]

Right. Before I tackle some of your points, you might do well to read this excellent post by Tim Holloway, which is part of discussion along similar lines, because he says what I'm trying do far better.

Brian Tkatch wrote:Variables don't exist. They are simply (strictly typed) named memory locations used for convenience and to ward off errors due to mistaken use.

That sounds oxymoronic to me. If they don't exist, then how can they possibly have a name?

And it certainly doesn't sound like the definition of a Java variable, which is a named item that does NOT have the word final in its definition.

Regardless of how variables are typed (i.e. supported by the language), ultimately, the compiler (or runtime) knows what to expect in the memory location.

Largely true for a language like Java, but not for C, where it might be a void* returned, for example, by a malloc() call, and certainly not true of assembler where it can contain virtually anything, including another memory address.

That is, x bits or bytes are the desired datum.

And that is certainly not true of Java. Item 2.7 of the JLS clearly states:
"The Java Virtual Machine does not mandate any particular internal structure for objects."

An array is different as we need two numbers. One, like before, how long each individual datum is, and two, how many of them there are. In some cases both numbers are recorded (where that is varies by language), in others, the array length is not recorded, but a stop byte is used (like C's string table where each string ends with a null byte.) Some, don't bother recording the length at all, and instead treat each individual array datum as a separate variable. So, the variable itself is actually an offset in the data segment, where the array offset (often, mistakenly called an index) if an offset from the start point. In either case, whether or not the length is stored, to retrieve an individual datum in the array, the offset is multiplied by the length of the type to find the starting point of the desired datum.

And as a description of what an array is in C, that sounds pretty reasonable; but for a Java array it makes far too many assumptions.

Specifically, it assumes that the "working part" of an array is a single piece of contiguous memory when, as you've already seen, the JLS doesn't mandate ANY internal structure for objects - and indeed, the whole ethos of Object-Orientation is that I, as a user, don't need to know how an object works. I only need to know what it does.
And what I know about a Java array is that it is a fixed-length list of items, each of which is uniquely identified by an index (note: not an offset), and that it has a length that I can access via its length attribute.

Furthermore, Java is used in all sorts of situations, including ones that might not lend themselves to the implementation (and what you described above IS an implementation) like C's. Take for example, a temperature gauge in a greenhouse that has to record thousands of readings an hour. It might consist of a chip with a JVM burnt into it and a small amount (lets say a few Mb) of RAM connected to a disk drive or SD card that it can use as storage. Should an array then be contiguous memory? What if I want to access element #217234675 (well within the limits of a Java array index)? Should the whole thing blow up because it doesn't have enough memory to get the resulting offset?

Wouldn't it make more sense to implement Java's array as something more like a piece of virtual memory, divided into 64K chunks? I want element #217234675, which I know lies in chunk # (217234675 >> 16), so first I check my little cache to see if it's already loaded in RAM. If not, I go to the disk and read it into RAM, replacing the "oldest" chunk (assuming they're arranged as an LRU cache). And then I do what you describe above, except with an index of (217234675 & 65536).

Completely different implementation, same outcome; and, more importantly, same semantics. My Java program doesn't need to know that anything different is happening in my temperature gauge than it would be if I was running it on a Cray.

As it so happens, Java treats arrays as if they were objects. Ultimately, however, it makes no difference. It's just an implementation detail.

Hopefully, what I wrote shows you that you've got it bass-ackwards: What you described is an implementation - in fact it's C's - but it's by no means the only one available. And the reason that what I described above works in Java is precisely because an array IS an object (and, of course, a type), so I can change it to work any way I please (Edit: actually, I couldn't because I'm a mere Java programmer paeon, but a JVM designer could).

Winston

[Mike. J. Thompson]

Brian Tkatch wrote:

Winston Gutkowski wrote:What theory?

Let's learn about variables! (Or, at least, my view of them.)

Variables don't exist. They are simply (strictly typed) named memory locations used for convenience and to ward off errors due to mistaken use.

This definition of existence doesn't make sense to me. The part I have highlighted in bold is simply a definition of a variable (not necessarily correct in Java as Winston has pointed out, but that is beside the point). I could use the same argument to to say that my house doesn't exist. it is simply a collection of bricks, mortar, tiles, wood and plaster that I use for convenience to keep the rain off. If things don't exist unless they can't be defined by simpler concepts then no emergent properties exist in any system, and the systems don't exist either because undoubtedly they are composed from other things.

Brian Tkatch wrote:Regardless of how variables are typed (i.e. supported by the language), ultimately, the compiler (or runtime) knows what to expect in the memory location. That is, x bits or bytes are the desired datum. Indeed, on the x86 processor, the variable is (the equivalent of, or is) an offset in the data segment which denotes where the datum starts, and the variable type (or the datum itself) defines how "long" the datum will be. The retrieval is stopped when reaching the allotted space.

No, the variable is more than just that base description of its physical parts. The language (which by the definition above doesn't exist either ;)) constrains what is allowed to appear in that space. These constraints are arguably more important to the definition of what a variable is than the physical description, and this links in with what Winston was saying. A given Java program can run on a number of different architectures, register based chips, stack based chips, different operating systems etc and it still behaves in the same way, and this is because the physical reality of the system running the program has to adhere to the abstract definition of the language in the JLS.

Brian Tkatch wrote:As it so happens, Java treats arrays as if they were objects. Ultimately, however, it makes no difference. It's just an implementation detail.

Java programs compile into bytecode, and the bytecode 'runs' in the JVM. The JVM has the concept of 'object' built into it. When loading a variable from memory there is a machine instruction used for loading objects (aload) which is different to the machine instruction used to load ints (iload) or longs (lload) etc. Arrays are loaded using aload, so are objects. You could argue that the JVM does not exist (it is just a running program), but that is just the implementation detail on a given architecture. There is no reason why you could not build a PC architecture that runs java natively (and in fact I believe there was a project to do just that, although I don't think it ever produced anything).

[Brian Tkatch]

Thank you for the detailed reply.

Brian Tkatch wrote:Variables don't exist. They are simply (strictly typed) named memory locations used for convenience and to ward off errors due to mistaken use.

That sounds oxymoronic to me. If they don't exist, then how can they possibly have a name?

In a compiled language, variables are replaced with offsets. Hence, the idea of a variable is removed from the system. Scripts may be otherwise, but the runtime that runs that script, ultimately, does it this way.

Regardless of how variables are typed (i.e. supported by the language), ultimately, the compiler (or runtime) knows what to expect in the memory location.

Largely true for a language like Java, but not for C, where it might be a void* returned, for example, by a malloc() call, and certainly not true of assembler where it can contain virtually anything, including another memory address.

Once a memory location is set aside for use, either it or the runtime has a listing of its length.

That is, x bits or bytes are the desired datum.

And that is certainly not true of Java. Item 2.7 of the JLS clearly states:
"The Java Virtual Machine does not mandate any particular internal structure for objects."

I stand corrected. However, this comment should be made on a different point. One way or another, the object knows the length. Otherwise, it would not know when to stop reading. Unless relying on a stop byte (or address), the length must be specified somewhere.

And as a description of what an array is in C, that sounds pretty reasonable; but for a Java array it makes far too many assumptions.

This is not just C. Most--if not all--languages do it this way. That is exactly the theory i speak of.

the whole ethos of Object-Orientation is that I, as a user, don't need to know how an object works. I only need to know what it does.

Which only proves my point! Regardless of how Java stores the data, conceptually, it is the variable that is arrayed, not the type.

And what I know about a Java array is that it is a fixed-length list of items, each of which is uniquely identified by an index (note: not an offset), and that it has a length that I can access via its length attribute.

Had that been true, the first item would be denoted by [1] not [0]. Other than a quirky programming book, all indices start from 1. The only reason to start from 0 is if it is an offset. (Or you're an evil un*x programmer that wants to continuously introduce bugs for the next few decades.)

Furthermore, Java is used in all sorts of situations, including ones that might not lend themselves to the implementation (and what you described above IS an implementation) like C's. Take for example, a temperature gauge in a greenhouse that has to record thousands of readings an hour. It might consist of a chip with a JVM burnt into it and a small amount (lets say a few Mb) of RAM connected to a disk drive or SD card that it can use as storage. Should an array then be contiguous memory? What if I want to access element #217234675 (well within the limits of a Java array index)? Should the whole thing blow up because it doesn't have enough memory to get the resulting offset?

Excellent point. No, really, that is a direct contradiction to mine. Nonetheless, that's still an implementation detail. Conceptually, it is contiguous. "That's the theory, at least." Yes, now we can just argue semantics over where the line that differentiates theory and implementation exists. You seem to draw it between use of the language and everything else (OO style, as you deftly pointed out). I want to draw it between use plus simple concepts and everything else. That is likely the root of our disagreement.

Wouldn't it make more sense to implement Java's array as something more like a piece of virtual memory, divided into 64K chunks? I want element #217234675, which I know lies in chunk # (217234675 >> 16), so first I check my little cache to see if it's already loaded in RAM. If not, I go to the disk and read it into RAM, replacing the "oldest" chunk (assuming they're arranged as an LRU cache). And then I do what you describe above, except with an index of (217234675 & 65536).

Changes by implementation.

[Paul Clapham]

There's a lot of stuff there, but basically my reaction is that you're too focused on how things work at runtime in some implementation of a language. That may be an important consideration in some languages but Java is designed so that you don't have to do that. It's true that Java is clearly designed to run on machines with 8-bit bytes and 32-bit twos-complement integer arithmetic and a particular floating-point implementation, but apart from that it really doesn't matter. An array in Java is a list of things which are numbered from 0 to N-1, and that's all you're supposed to know. Sure, when it's running it's very likely to be implemented as a contiguous piece of memory broken down into N equal-sized pieces, but you shouldn't care about that. There's supposed to be a layer of abstraction between source code and implementation and Java tries to keep that abstraction as un-leaky as possible.

Unfortunately your post sometimes descends into word salad like for example "it is the variable that is arrayed, not the type". With vague and sloppy language like that you can wave your hands and assert anything. Arrays exist -- at least insofar as any concept can be said to "exist" -- but there's nothing being "arrayed". A variable certainly isn't "arrayed"; it's possible for a variable to refer to an array, though. (Java programmers sometimes get sloppy and say that a variable "contains" something, which is only partly true. A variable can contain a primitive value or a reference to an object, nothing else.)

[Brian Tkatch]

Paul Clapham wrote:your post sometimes descends into word salad like for example "it is the variable that is arrayed, not the type". With vague and sloppy language like that you can wave your hands and assert anything. Arrays exist -- at least insofar as any concept can be said to "exist" -- but there's nothing being "arrayed".

I'm not going to disagree with you. I will just point out this goes back to my comment "Also, he puts [] after args, not String, which is technically accurate (the variable is the array, not the type) which gives me more confidence in him." Which is what we are arguing about. It's a disagreement over semantics with a touch of (misunderstood) reality. :)

[Mike. J. Thompson]

In java, String[] is the type, not String. I imagine Java only allows the brackets in other places to make it familiar to C/C++ programmers.

[Winston Gutkowski]

Mike. J. Thompson wrote:In java, String[] is the type, not String. I imagine Java only allows the brackets in other places to make it familiar to C/C++ programmers.

And so we've come full-circle, because that's basically what I said here to spark off this whole 'fork'.

@Brian: What I will agree with you about is that Java's array class is a bit of an oddball. There is, for example, no Array or array.java file (at least not in java.lang, which is where you would expect to find it)) - and you won't find an API page for it. But that doesn't make it any less a type; as I've tried to explain.

I also think I see your point now that when we refer to an element of an array, we use the name of the variable (or constant) that references it, along with a built-in operator ([]), so it appears that the name is being "arrayed". However, I see that as no different to getting an element from a List: we use the name of the variable (or constant) that references the List, plus a method call (get()) with an index value. I'm pretty sure that Mike's right, and the only reason Java's gurus chose to implement array syntax the way they did was for familiarity.

Also: if you're correct, that would make 'array' (or "arraying") a function, and that's definitely not the case in Java, since the language doesn't support first-class functions (yet ).

Winston

[Campbell Ritchie]

Brian Tkatch wrote:Thank you for the detailed reply.
. . .

Agree. I think I shall have to get a few whips out and drive some dogies in the direction of the previous posters who have gone to so much effort to answer.

In a compiled language, variables are replaced with offsets. . . .

That is simply an implementation detail which has no bearing on the higher‑level language. And Java® is not a compiled language.

. . . Once a memory location is set aside for use, either it or the runtime has a listing of its length. . . .

That is an implementation detail which varies from compiler to compiler. The older C compilers would compile a String to a *char which has no indication of its length at all. It simply continues until a \0 (=null) char is encountered. In fact older C/C++ compilers kept no record of the length of any arrays.

. . . This is not just C. Most--if not all--languages do it this way. That is exactly the theory i speak of. . . .

You are on very dubious ground saying that all, or even most languages maintain arrays the way that C does. There is no theory to go with it at all, otherwise all languages would do it the same way. Since there is no internal structure mandated for a Java® array, what you are describing are implementation details which do not concern us. The index shown when you write a Java® array is neither an index showing you that you are at a particular memory location nor an offset (as it would be in C). It is an instruction to the array which is an object to find the (n − 1)th element, designed to look like C‑style offsets.

The only theory we have is that all code, data, memory locations, everything, on a computer is coded into binary numbers and handled as sequences of bits which consist of electrical currents turned on or off.

This discussion is far too difficult for the beginning forum, so I shall move it.

[Campbell Ritchie]

Winston Gutkowski wrote: . . . I'm pretty sure that Mike's right, and the only reason Java's gurus chose to implement array semantics the way they did was for familiarity. . . .

Agree. But I think you don't mean semantics, but syntax.

Not only does the syntax of Java® arrays appear familiar to C/C++ programmers, but the behaviour of arrays confronted with the increment operators (e.g. --i and i++) and the % operator and even h & c − 1 are familiar and predictable when 0‑based indexing in used.
The semantics of Java® arrays is different from C arrays because Java® arrays (as already shown) are full‑blown objects whereas C arrays are simply pointers with offsets. That is why you can replace myArray[i] in C with *(myArray + i) and why you can exceed the bounds of an array in C getting an incorrect result whereas a Java® array would throw an Exception.

[Winston Gutkowski]

Campbell Ritchie wrote:Agree. But I think you don't mean semantics, but syntax.

Quite right. Smack hand.

Winston

[Brian Tkatch]

Sheesh, all this for stating a preference!

While i disagree for the reasons i have already stated, i am really enjoying reading the posts here. I think i'm learning from that too!

[Campbell Ritchie]

And we are learning by disagreeing with you

The Java™ Tutorials does say

// this form is discouraged
float anArrayOfFloats[];

However, convention discourages this form; the brackets identify the array type and should appear with the type designation.

[Winston Gutkowski]

Brian Tkatch wrote:Sheesh, all this for stating a preference!

Yeah. Terrible, innit.

While i disagree for the reasons i have already stated, i am really enjoying reading the posts here. I think i'm learning from that too!

I'm wondering what languages you've used? Your assumptions seem to be very C-centric, and I know I had to shed a lot of preconceptions when I came from that world. I guess we tend to like what we're accustomed to. But now: I'm a confirmed Java disciple and wouldn't have it any other way.

Winston

[Brian Tkatch]

Campbell Ritchie wrote:And we are learning by disagreeing with you

The Java™ Tutorials does say

// this form is discouraged
float anArrayOfFloats[];

However, convention discourages this form; the brackets identify the array type and should appear with the type designation.

I love Oracle. I follow their advice inside the database, mostly. In everything else, i really don't care about their opinion. I don't mean that in a mean way. I simply don't care.

I am also unlikely to use any of the java conventions for naming or formatting. I despise them with a passion. As my code is only for me (i can't imagine doing it as a job) i think i'll be okay. Though, i am a little wary about posting here when i need help.

I:

use underscores.

despise camelcase (though, i may use Init_Caps.)

make sure braces line up.

put nouns before verbs (x_get(), x_set())

name things by what they are as opposed to what they do

I wish java would stick to being a language and stop forcing so much style. I find people's code so hard to read because of it.

FWIW, in SQL, i add tons of whitespace:
SELECT column, column FROM Table, Table WHERE clause AND clause;I often reformat any code i'm asked to fix. It helps me understand what they are trying to do.

Arrays are a small part of all this. Unfortunately, i don't think i can support starting them all from 1, but at least i can declare them the way i understand them! And if that makes me like a book more, well, so be it. :P

[Brian Tkatch]

Winston Gutkowski wrote:I'm wondering what languages you've used? Your assumptions seem to be very C-centric

I never finished learning c, though in CS1 and CS2, c++ was the language.

I started with apple BASIC, moved on to Microsft Basic in all its flavors and VB. Let's see, REXX, VX-REXX, SQL, t-sql, PL/SQL, PL/1, assembly, perl, bash, and a few others here and there. I learn languages as needed, i care more about the theory than the language (though, i have a special liking to pre-ANSI SQL.)

[Campbell Ritchie]

With this ring, I thee wed.

A phrase familiar to anybody who has watched movies from the 1930s. But not correct, normal, English grammar. If you want to talk to everybody else, you have to talk the language they talk, and if you want them to understand you, you have to talk the way they talk. If you insist on talking differently, you cannot blame others if they don't understand you.

[Winston Gutkowski]

Brian Tkatch wrote:Let's see, REXX, VX-REXX, SQL, t-sql, PL/SQL, PL/1, assembly, perl, bash, and a few others here and there...

Blimey, REXX. That's a blast from the past - and actually one of the IBM languages that I really liked, along with PL/1 (I still don't understand why Java's String class doesn't have a verify() method - incredibly useful).

I note that, other than SQL, they're all procedural though, which may be a bit of a gap. And I say that because, even though I had some C++ under my belt before I started Java, it took me 7 years before my "Eureka" moment.

Anyhew, glad to have you on board, even if you are wrong. And a great discussion.

Winston

[Brian Tkatch]

Campbell Ritchie wrote:

With this ring, I thee wed.

A phrase familiar to anybody who has watched movies from the 1930s. But not correct, normal, English grammar. If you want to talk to everybody else, you have to talk the language they talk, and if you want them to understand you, you have to talk the way they talk. If you insist on talking differently, you cannot blame others if they don't understand you.

I understand that, and that's why i mention it outright. If i find people dislike the way i code, if i really want their help, i'll modify my code. I've done that before. In any case, there's a lot to learn even without code. Heck, i think i enjoy this site because of what it is more than what i get from it.

[Campbell Ritchie]

Anyway, s Winston says, we enjoy having you here; such disagreements to make for good discussions.

[Brian Tkatch]

Campbell Ritchie wrote:such disagreements to make for good discussions.

Absolutely.