Talk:Reference (computer science)

message: While this topic has close ties with references, in that references are the device that enables external storage, it seems like it shouldn't merit taking up such a large proportion of the article. Then again, where else could it go? I'm not sure.
Derrick Coetzee 00:52, 10 Jan 2004 (UTC)
thread_title:  Internal/external storage 

message: In the section on language support, the following statement is made in regards to Java, C#, and Visual Basic:
:In those managed languages, the references are actually pointers of pointers of the referred data.
This statement is mangled at best, and I believe not just confusing, but also incorrect (although since I can't be sure what it is trying to say, correctness is difficult to ascertain.)  Does pointers of pointers mean pointers to pointers (handles)?  If so, this isn't correct, at least not for Java.  The language does not specify the mechanism used for managing memory, but certainly the vast majority of JVMs don't use handles.
In fact, I'm not sure that you can group these three languages together in regards to their use of references. -- Doug Bell (talk/contrib) 09:57, 16 January 2006 (UTC)
replies: text: I would rearrange this by adding a discussion of handles and mentioning that some implementations of some languages use them. Deco 18:18, 16 January 2006 (UTC)
thread_title:  Pointers of pointers 

message: The sentence following the pointers of pointers sentence above is:
:In C/C++, the reference concept of managed languages means two-step pointing.
It seems that the author is attempting to talk about indirection through handles, but I'm not familiar with the terminology two-step pointing. Since I'm pretty sure I'm well above average in familiarity with this subject, this either needs rewording or some explaination.
Also, the reference concept of managed languages might be clearer as the concept of references in managed languages, but again I'm not even sure that's the meaning the author intended.
The whole language support section seems a bit rough. -- Doug Bell (talk/contrib) 12:28, 16 January 2006 (UTC)
replies: text: Agreed, I don't like how this is worded. It's fine to describe specific behaviour of Microsoft's implementation of .NET, but we should word it as such and in particular not attempt to view C/C++ which long predated .NET from the perspective of .NET. Deco 18:17, 16 January 2006 (UTC)
thread_title:  Two-step pointing 

message: Continuing the string of obscure references (pun not intended), the sentence following the two-step pointing sentence above is:
:The Garbage Collector is the sole actor that can directly access the mid-step pointers, which cause the opacity.
The terminology mid-step pointer is apparently referring to the hidden opaque pointer in a handle.  The form in which this term is used requires the term to stand on its own, but I can find no other reference to mid-step pointer.
:I concur that this is confusing. Deco 00:18, 17 January 2006 (UTC)
replies: text: Actually after reading opaque pointer this seems to have nothing to do with, well, what I would normally think of as opaque pointers. It seems to be describing some kind of data hiding technique for classes. Deco 01:20, 17 January 2006 (UTC)
replies: text: I agree that the description of opaque pointer does not match your description of opaque (below) as it applies to references. Opaque as discussed in opaque pointer is referring to the opacity of the referenced object, whereas opaque as applied to "reference" in the article is referring to the opacity of the reference value. Nevertheless, the term "opaque" refers to information hiding in both cases. Simply replace opaque pointer with pointer in my original statement to correct it. I think this discrepency in the usage of "opaque" just further illustrates the point that the meaning of opaque as used in the article needs to be defined. -- Doug Bell (talk/contrib) 19:39, 17 January 2006 (UTC)
replies: text: Sorry, I know what you meant. I agree that clarification and/or rewording is needed. Deco 21:23, 17 January 2006 (UTC)
thread_title:  Mid-step pointers 

message: The article uses the term opaque in three places—once discussing smart pointers as opaque data structures, once discussing opaque references in Lisp and, finally once discussing much more opaque references in Java, C# and Visual Basic.  There needs to be some definition of opaque here, particularly what it means to be much more opaque.  (Note that I added a Wikilink to opaque pointer at the first reference, but this still doesn't make the use of the term clear in this article.)
I would have attempted to fix some of this up, but a) it wasn't clear to me what the author of those passages was trying to say, and b) because for a small article, this article has a long history of being editted.  Discussion welcome. -- Doug Bell (talk/contrib) 09:57, 16 January 2006 (UTC)
replies: text: To say that a reference is opaque is to say that the number of possible operations on it, particularly dangerous operations, is restricted. The vague phrase much more opaque simply means many less such operations are possible. I guess it does need to be fixed up. Deco 10:04, 16 January 2006 (UTC)
thread_title:  Opaque and much more opaque 

message: I have removed "The C programming language introduced the pointer ..."  Pointers in programming languages are at least as old as  ALGOL.  --75.15.154.154 05:59, 4 July 2007 (UTC)
thread_title:  Pointers: a little historical perspective 

message: Please rewrite the first paragraph so that you do not confuse 'directly' and 'indirectly'.  —Preceding unsigned comment added by 203.222.167.145 (talk) 08:02, 3 August 2009 (UTC)
replies: text: The point that must be emphasized is that a reference does not need any significant lookup or computation.  This is the feature that distinguishes a reference from a key or indetifier.  I tried to change "directly access" to "have immediate access" to avoid the alleged confusion with "indirect access", but then noticed that this change creates another confusion with "immediate operands" where a computer instruction contains the data rather than its address.So I am changing it back to "direct access".  On second thought, the claimed direct/indirect confusion does not seem to exist.  "Direct addressing" usually means that the instruction contains a reference to the data, so the word "direct access" is appropriate in that context.  In architectures where memory is addressed only through registers, one may say "register addressing", so "direct access" causes no confusion there either.  Finally, "indirect addressing" is when one has a refernce to a memory location that contains a reference to the data; so the first memory access is "direct", the second one "indirect".  All the best, --Jorge Stolfi (talk) 13:44, 3 August 2009 (UTC)
thread_title:  Direct or indirect access? 

message: Great article! Could be improved by explaining the difference between pointers and opaque references like those of Java and C#. This is a good explanation: Pointers vs References  — Preceding unsigned comment added by 50.181.81.149 (talk) 21:33, 2 May 2015 (UTC)
thread_title:  Pointers vs. Opaque References 

message: See Talk:Linked_list#Internal_and_external_storage. Dcoetzee 11:37, 4 March 2010 (UTC)
thread_title:  Internal and external storage 

message: The given formal representation is deeply flawed:
"If we have a set of data D, any well-defined (single-valued) function from D onto D ∪ {null} defines a type of reference, where null is the image of a piece of data not referring to anything meaningful."
First, why is the map from D to D? The set of keys is completely different from the set of data. Also, why should this map be "onto" (i.e. surjective)? First, there may be data objects that are not reachable through reference, for whatever reason. Second, even if each object had a key, saying "onto D ∪ {null}" means that there must always be a key that yields null, i.e. that the set of keys must contain invalid references. Why should that always be the case?  — Preceding unsigned comment added by Vog (talk • contribs) 09:18, 23 February 2017 (UTC)
thread_title:  Formal representation is flawed