4 ms·

> > You get at the thing being pointed to by dereferencing the pointer. > Which you can't do in Java! There's no * operator. . and array indexing dereference

by kbp 8y ago

> > You get at the thing being pointed to by dereferencing the pointer. > Which you can't do in Java! There's no * operator. . and array indexing dereference pointers in Java, just as -> and array indexing do in C. I've already mentioned this several times. > all these concepts from C/C++ that just aren't there in Java. The Java language spec disagrees with you (before you said that explanation was pedantic; now it's incorrect?). As well, C and C++ did not invent pointers; you're the one insisting that Java's pointers aren't pointers because they don't behave identically to C's, I was saying that the specific differences don't change the fact that they're both flavours of pointer. No one is claiming that Java is source-compatible with C. And really, there's no alternative explanation. You can learn each special case individually if you want and let your brain connect the dots to form the notion of how to use a reference without having sat down and thought about it and unified the concept, but that seems like so much work to get around learning a pretty simple idea that fully explains all of it without any special cases.

lmm 8y ago
> . and array indexing dereference pointers in Java Neither of them will give you "the thing that's pointed to". And . very deliberately looks like a direct accessor in C/C++, not the dereferencing accessor ->. > As well, C and C++ did not invent pointers; you're the one insisting that Java's pointers aren't pointers because they don't behave identically to C's, I was saying that the specific differences don't change the fact that they're both flavours of pointer. The essence of a pointer - right there in the name - is that it's a thing that points to another thing. If the thing language has doesn't point to another thing in the language, you can't call it a pointer IMO. > And really, there's no alternative explanation. You can learn each special case individually if you want and let your brain connect the dots to form the notion of how to use a reference without having sat down and thought about it and unified the concept, but that seems like so much work to get around learning a pretty simple idea that fully explains all of it without any special cases. Disagree. If you learn: objects are passed by reference, == is a nonsense historical wart that you never use (as are arrays and primitves), and the default implementations of equals()/hashCode()/toString() should never be used, then you get a consistent working language that's much simpler, without having to involve anything from outside the language.
- deleted 8y ago
  [deleted]
- deleted 8y ago
  [deleted]
- kbp 8y ago
  > If the thing language has doesn't point to another thing in the language, you can't call it a pointer It points to a tangible thing in the language, the object that you're operating on, that thing just isn't a first class value, so you can't store it in a variable or pass it to a function. If this reasoning means that Java doesn't have pointers, then C doesn't have functions or arrays, either. > If you learn: objects are passed by reference They're visibly not passed by reference, though, you forgot the extra rule that using '=' on a parameter is also broken and to be avoided (from the perspective of pass by reference). So your explanation has 7 additional special rules to learn, including leaving multiple very common elements of the language at "just don't touch that", and still assumes the learner knows what a reference is anyway; why not just use the language of the Java spec and describe the actual semantics as they're defined, instead of this awkward simplifcation that takes longer to explain and involves more concepts? > without having to involve anything from outside the language. You also keep repeating this point even after it's been explained to be false; what language are you referring to when you keep saying Java doesn't have these concepts? The Java language spec from Oracle says: "4.3.1. Objects "An object is a class instance or an array. "The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." They are also a part of the visible semantics of the language, as has been explained over and over in this thread, and that way you get a simple, consistent language, and it's one that people actually use instead of a made-up, more complicated subset.
  - lmm 8y ago
    > If this reasoning means that Java doesn't have pointers, then C doesn't have functions or arrays, either. Saying C doesn't have functions would be more like saying Java doesn't have objects: rather I'd say that C doesn't have pointers to functions (but has various syntactic weirdnesses to allow a function to behave like a pointer in some contexts, since the rest of the language has a value/pointer distinction). "C doesn't have arrays, only some syntax sugar over pointers" is a common view among working C programmers. It's not a completely accurate model of the details of the language, but it can lead to fewer mistakes than not believing it (e.g. a function declaration like "int foo(int bar[5])" is actively misleading, and this is the kind of mistake someone who believes "C has arrays" may make and someone who believes "C doesn't have arrays, only some syntax sugar over pointers" won't make). > They're visibly not passed by reference, though, you forgot the extra rule that using '=' on a parameter is also broken and to be avoided (from the perspective of pass by reference). Point, though I think linters and IDEs warn on that one anyway. > your explanation has 7 additional special rules to learn Not really - you're going to have to explain the importance of not calling .equals()/.hashCode()/.toString() on random Objects either way, and you don't have to teach any extra special rules to avoid ==, != or arrays or primitives - you just don't teach any of those things. > including leaving multiple very common elements of the language at "just don't touch that" Any introduction to Java is going to involve a very long list of "don't touch that" (corba, dates, ejb, finalizers, monitors, AWT...), it's the nature of a language with a backwards compatibility history. > why not just use the language of the Java spec and describe the actual semantics as they're defined, instead of this awkward simplifcation that takes longer to explain and involves more concepts? I don't think either of those things are true. You have a bunch of extra concepts: class instances, references, and arrays - and class instances are particularly difficult to explain since they're not values in the language.

by kbp 8y ago

lmm 8y ago

> . and array indexing dereference pointers in Java Neither of them will give you "the thing that's pointed to". And . very deliberately looks like a direct accessor in C/C++, not the dereferencing accessor ->. > As well, C and C++ did not invent pointers; you're the one insisting that Java's pointers aren't pointers because they don't behave identically to C's, I was saying that the specific differences don't change the fact that they're both flavours of pointer. The essence of a pointer - right there in the name - is that it's a thing that points to another thing. If the thing language has doesn't point to another thing in the language, you can't call it a pointer IMO. > And really, there's no alternative explanation. You can learn each special case individually if you want and let your brain connect the dots to form the notion of how to use a reference without having sat down and thought about it and unified the concept, but that seems like so much work to get around learning a pretty simple idea that fully explains all of it without any special cases. Disagree. If you learn: objects are passed by reference, == is a nonsense historical wart that you never use (as are arrays and primitves), and the default implementations of equals()/hashCode()/toString() should never be used, then you get a consistent working language that's much simpler, without having to involve anything from outside the language.

deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
kbp 8y ago
> If the thing language has doesn't point to another thing in the language, you can't call it a pointer It points to a tangible thing in the language, the object that you're operating on, that thing just isn't a first class value, so you can't store it in a variable or pass it to a function. If this reasoning means that Java doesn't have pointers, then C doesn't have functions or arrays, either. > If you learn: objects are passed by reference They're visibly not passed by reference, though, you forgot the extra rule that using '=' on a parameter is also broken and to be avoided (from the perspective of pass by reference). So your explanation has 7 additional special rules to learn, including leaving multiple very common elements of the language at "just don't touch that", and still assumes the learner knows what a reference is anyway; why not just use the language of the Java spec and describe the actual semantics as they're defined, instead of this awkward simplifcation that takes longer to explain and involves more concepts? > without having to involve anything from outside the language. You also keep repeating this point even after it's been explained to be false; what language are you referring to when you keep saying Java doesn't have these concepts? The Java language spec from Oracle says: "4.3.1. Objects "An object is a class instance or an array. "The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." They are also a part of the visible semantics of the language, as has been explained over and over in this thread, and that way you get a simple, consistent language, and it's one that people actually use instead of a made-up, more complicated subset.
- lmm 8y ago
  > If this reasoning means that Java doesn't have pointers, then C doesn't have functions or arrays, either. Saying C doesn't have functions would be more like saying Java doesn't have objects: rather I'd say that C doesn't have pointers to functions (but has various syntactic weirdnesses to allow a function to behave like a pointer in some contexts, since the rest of the language has a value/pointer distinction). "C doesn't have arrays, only some syntax sugar over pointers" is a common view among working C programmers. It's not a completely accurate model of the details of the language, but it can lead to fewer mistakes than not believing it (e.g. a function declaration like "int foo(int bar[5])" is actively misleading, and this is the kind of mistake someone who believes "C has arrays" may make and someone who believes "C doesn't have arrays, only some syntax sugar over pointers" won't make). > They're visibly not passed by reference, though, you forgot the extra rule that using '=' on a parameter is also broken and to be avoided (from the perspective of pass by reference). Point, though I think linters and IDEs warn on that one anyway. > your explanation has 7 additional special rules to learn Not really - you're going to have to explain the importance of not calling .equals()/.hashCode()/.toString() on random Objects either way, and you don't have to teach any extra special rules to avoid ==, != or arrays or primitives - you just don't teach any of those things. > including leaving multiple very common elements of the language at "just don't touch that" Any introduction to Java is going to involve a very long list of "don't touch that" (corba, dates, ejb, finalizers, monitors, AWT...), it's the nature of a language with a backwards compatibility history. > why not just use the language of the Java spec and describe the actual semantics as they're defined, instead of this awkward simplifcation that takes longer to explain and involves more concepts? I don't think either of those things are true. You have a bunch of extra concepts: class instances, references, and arrays - and class instances are particularly difficult to explain since they're not values in the language.