On Sun, Nov 17, 2019, at 07:26, Richard Damon wrote: > I am not sure about C#, but in C++, a base language for C#, you can not > take the address of a variable of reference type, if you do, you get the > objected referred to, not the reference. References are essentially > constant pointers, and can not be re-seated to reference another object.
C# is not very closely related to C++, calling it "a base language" would be inaccurate IMO. It's much more similar to Java in many ways. In particular, its "reference types" have absolutely nothing to do with C++'s references. They're much more similar to Java or Python object types. The "ref" references used for call-by-reference arguments are much more similar to C++ references [and there's no analogous feature in Java], but somewhat more restricted (they can't be used as a member of a class, for example) The ability to make a "ref" reference to a variable of reference type is analogous to being able to make a reference to a pointer in C++, even though C#/Java/Python object references are not really the same things as pointers due to e.g. not having pointer arithmetic, etc. (the C++ .NET compatibility layer calls these 'handles', and uses the ^ character for them. The "ref" variables themselves use a % character, since they have to be distinct from &-references due to their role in the .NET garbage collection system) > I suppose one way at looking at Python's name binding system (maybe not > entirely accurate) would be to say that all Python names act like > references, but that assignment, rather than being applied to the > referred to object, re-seat the reference to point to the new object. As > such, you can't get a reference to the name, to let one name re-seat > where another name refers to. I guess if anything this discussion has proven to me that C#'s decision to use "reference" for two unrelated concepts in fact causes more confusion than I thought it would from the perspective of the amount of .NET experience I have. However, my point was that the basic idea of pass by reference, even if it should be called something else (if implemented in Python it would probably use cell objects as "references", with some other kind of wrapper object being needed to handle the case of the target not being a local variable) is not fundamentally inapplicable to Python just because of the object reference model. Call by cell? Call by getter/setter? There's an old saying that one of the hardest problems in computer science is naming things. -- https://mail.python.org/mailman/listinfo/python-list
