guy keren wrote: >On Sun, 4 Dec 2005, RaeNye wrote: > > > >>Alas, the *concept* of reference is common to the human mind and human >>language! >> >> > >so your initial claim of being able to explain the examples without using >references, is false. > >so we now agree that we need to teach two concepts: names and references. > > What I call "reference" is implicitly included in most people's (most non-programmers, at least) understanding of what the word "name" means.
The same thing also appears in other concepts, such as lists. While a python list does not fully coincide with the daily use of the word, it almost does. My "physical note with list of items" example in another post might help explaining the (minor) difference. You do have to talk about names. You do have to talk about lists (and probably about dicts and tuples, which are other types involving references). Technically you don't HAVE to explain references as a seperate concept, but it might prove useful (e.g. when explaining the fine details about lists). The point is - people DO know about names and it might be easier to explain references (or list items) by using the example of names than the other way around. p.s. : A standalone object implementing the "reference" concept would coincide with a pointer (actually a weakref is almost exactly that) - I don't think we should confuse them with these. >now comes the next issue: > >you can change a list. >you can't change a number. >you can't change a string. >you can't change a tuple. > >in order to explain this, i will use the 'mutable' Vs. 'immutable' issue. > > So - some objects you can change, some not, some you can change but don't. (Note that a tuple contains references even though you can't change it). What's so special about that? Do you define "immutable" any other way than "object that can't be changed"? I'd only mention mutability when your'e about to explain about dicts. You can only use immutable objects as keys for a dictionary. This is a fact that needs to mentioned, even if you don't explain why. (the explanation involves considerations of efficiency, and understanding how dicts are implemented - might be included in the data-structures reading material, but not strictly necessary for this course). >do you have a way to aovid that? > >the rest of what you write is not realy important, except for one point >that i will emphasize: > > > >>Why don't you complain about the following line of code? >> >> >>>>>a = [1, 1] >>>>> >>>>> >>It shows the exact same "problem" - how can the number 1 appear twice in the >>same list? >> >> > >when a person thinks about the number '1', they do NOT think of it as an >object. thus, they are not surprised to see it used twice in a list. the >concept that even a single number is an object is not something natural - > > Depends on how you define object. Common interpretation of the word is "physical object" like "car", but people do say "abstract object" when referring to e.g. numbers. In the context of a computer language, a number is about as physical as a car, so by "python objects" we mean any kind of data. This might need to be explicitly said. However, it is completely natural to give names to numbers - "two","my age", etc. And it's no surprise you can put them in a list. Many people even have the same phone-number listed more than once in their diary. >you don't think of "1+2" as "1.add(2)" (i.e. as an operation of 'add 2' on >the object '1'). you just think of the operationg of adding `1 and 2 >together. you only consider it when you learn about languages such as >smalltalk (which started this "everything is an object" concept. in >smalltalk there are no operators. in order to perform addition, you write >something like: > >[1 add: 2] > >(i.e. send the message 'add:' to the object '1', supplying the object '2' >as a parameter). > > > ahh... touchy point. In fact: >>> (1).__add__(2) 3 >>> Now if you insist on using methods exclusively, you might ask: is 1+2 actually "(1).__add__(2)" or "(2).__radd__(1)"? You quickly get into the following quicksand: http://www.python.org/doc/2.4.2/ref/coercion-rules.html As someone who had the unpleasant experience of having to use and implement such methods, I can tell you that's one big nasty wart in python (luckily their'e aiming to phase that out towards python3). I believe that since both operands have symmetric status, the right thing to do would be to treat the operation as a seperate entity, somewhat like in C++ "friend T operator+(T first, T second)". Unlike Java, we do have simple functions in python. >since python is not pure about the syntax, we don't need to be pure about >explaining things. > > > >>Surely you wouldn't even consider the thought that these are different >>"instances" of the number 1 (although this might be true in other >>programming languages); >> >> > >actually - this is exactly what i wold have thought before being taught >programming - that you can use the number 1 here, and there, and i'd not >even bother thinking that they are the same '1'. > > If you ever wrote buggy fortran77 code, you might have quickly and painfuly learned that it's the same instance ;-) (stepping over constants such as 1 or 0 is a very real and common bug there, and it can have unbelievably confusing and hard to track results - I imagine they added some safety measures in fortran90). > > >>Your concept of what a list /is/ should be ready to accept an object >>appearing as multiple elements in it. >> >> > >in other words - references. that's what i wanted to show in the first >place - thanks for helping ;) > > > >>I don't say the concept of reference is avoidable. I only refuse to present >>it as a special thing. >> >> > >when you teach programming - everything must be explicit. what you think >is intuitive - is intuitive in a different way to different people. >avoiding talking about something does not make it clear. > > > Different people do have different intuitions about abstract or invented concepts. That's why I strongly suggest using concrete "daily life" examples (e.g. for names and for lists. You can use these examples to extract the common "reference" property inherent in these two concepts).