anything like C++ references?
Adam Ruth
owski at hotmail.com
Tue Jul 15 13:21:39 EDT 2003
More information about the Python-list mailing list
Tue Jul 15 13:21:39 EDT 2003
- Previous message (by thread): anything like C++ references?
- Next message (by thread): anything like C++ references?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Stephen Horne <intentionally at blank.co.uk> wrote in message news:<9mh6hv45v18apgn6lp7bo6mm63e5oba9rd at 4ax.com>... > >You say that there is one gold standard definition for what a variable > >is. Yet even though C++ deals with variables in three semantically > >distinct way, they are somehow all valid within that definition? > > C++ does not deal with variables in three semantically distinct ways. > It provides a wide range of data types (including pointer types and > reference types) and, in keeping with the mathematical concept of an > abstract data type, each has both its own set of values and its own > set of operations. The only way in which semantics vary from variable > to variable is in that some of those semantics are tied to the > abstract data type. I was going to stay out of this thread because we were just retreading the same ground with different wording, and it was pointless. But here you've brought up something that is completely false, and new to the discussion: > C++ does not deal with variables in three semantically distinct ways. You're correct, it deals with variables in more than three semantically distinct ways. Now, semantic may mean something different to you than it does to me, but if I have two variables and I cannot use the same syntax with each, they're semantically different. Let's look at some of the differences. int i = 1; *i = 5; Does this work? No, it doesn't, because pointers are semantically different than non pointers. register int x = 5; int *y = &x; This also cannot be done. Why? Different semantics for register variables. int y = 1; int x = 2; int &m = y; m = x; Now, here are two problemmatic things. 1) References are just pointers with syntactic sugar, right? Well, it's a pretty thick layer of sugar. Not only can't you use * to dereference, but you don't use & to get the reference, and you don't use -> to access members. References are in the netherworld between pointers and regular variables. In some cases they act like variables, in others they act like pointers. Now that's confusing. 2) C++ makes a strong distinction between the initialization operator, =, and the assignment operator, =. Both const and reference variables use them differently. To me, that's a really big violation of proper 'computer science', because conceptually they're the *same* thing. But because of context, C++ makes a distinction. Python has no such distinction, initialization and assigment are always the same. (This is true of all static languages with the concept of a constant, and I don't really disagree with it as a valuable idiom, but it is inconsistent internally, where Python is consistent. Do any languages use a different operator for initialization?) Now here's one that's very germain to the topic: void mod(char *value) { value[0] = 'a'; } char *str = "hello world"; mod(str); What about this one? str is immutable (or more accurately, its value is immutable). How does mod know this? It doesn't, it's a seg fault. Now, not only is str immutable, but its not inferrable at any point within the function (I guess you could look at it's region in memory, but then you're really down at the implementation layer). Does this violate 'computer science' principles? I'd say it violates the principles you've put forward. > Even when using pointers, the binding of variables to > values is preserved. It is merely that pointer values provide an > indirect way of referencing a store location, or placeholder, which > may be manipulated (ie bound to a different value) using some other > means of identifying that placeholder. The only real difference between this and Python is that in C you're looking at a region in memory that is most always mutable. Python doesn't need to follow this idiom to be correct. Why? Because Python doesn't have regions in memory, it's a non-existent concept. In C you have variable -> memory -> value. In Python you have variable -> value. You may not like this, but I don't think you can correctly say that the C way is 'better' or 'more in line with computer science'. And it certainly isn't more confusing, that's a crock. What you need to know to work with variables in Python is a much smaller base of knowledge than what you need to work with C++. To you it doesn't seem that way, because C++ is second nature to you. But if you took two novice programmers and tried to explain both ways, the persion learning Python would 'get it' much sooner, because there's much less to 'get'. All I have to do is think about the blank stares I get when I try to teach a new programmer about pointers. It's a difficult concept to get, and it's difficult mainly because you need to understand implementation to get it, something you constantly accuse Python of. In C++ you *need* to know implementation of pointers, references, etc to be effective. And you will be surprised quite often by confusing and unexpected semantics and behavior. That just doesn't exist in Python, when I make an assignment, I *know* what's going to happen. And even if C++ is more 'correct' from a computer science standpoint, Python is more simple, concise, and consistent. I'll take that any day. Getting back to the original topic of the discussion, pass by reference. There's a very, very good reason Python doesn't do it: It's not necessary. It only exists in C and C++ to overcome limitations in both languages. Those limitations *don't* exist in Python, so there's no need for pass by reference. There is no example of a situation where pass by reference is the only way to do things, in fact, the way that Python works allows for much *better* ways to achieve those goals. It's simply unnecessary.
- Previous message (by thread): anything like C++ references?
- Next message (by thread): anything like C++ references?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list