Subject: Re: Newbie Q: Methods & Packages From: Erik Naggum <erik@naggum.no> Date: 1999/09/05 Newsgroups: comp.lang.lisp Message-ID: <3145544479675346@naggum.no> * Andrew Cooke | - first, there doesn't seem to be anything in the package system that | decides which namespace (function, variable, whatever - I remember | something saying there were 7) within a particular package a symbol | refers to. huh? a symbol is a name of something. a string of letters and whatever is the external form of that name. when read by the Lisp reader, the package looks for a symbol with the name with that external form in the specified (or current) package, and that symbol is used. at no point in this process does the "something" the symbol names enter the picture. however, the "something" is referenced by the user of the symbol, and if that is SYMBOL-VALUE, you get the variable, if it is SYMBOL-FUNCTION, it is the functional value, if it is FIND-CLASS, it is the class, if it is THROW, it it the CATCH tag with that name, but you might as well consider the possibility of an ASSOC list or a HASH-TABLE with a symbol as key, so counting namespaces is silly. | Does that mean that if I have a constant and a function with the same | name (it's OK, I've read a Lisp style guide and I have some common sense, | but out of curiousity...) both are visible if declared external? yes. there's nothing wrong with using the same name for several things. after all, that's the very idea! it is also far better than trying to invent two names for the same thing. e.g., if you have a VOTE class, would you want to call a function CAST-VOTE instead of just VOTE? | Is there no way of controlling this? no. the key is to understand it. if you want some property of a symbol to be exportable and another not, you can either document it and expect people to read the documentation, or you can call it something else. | - second, my confused reference to circularity in the original post was | because I couldn't see how methods with the same interface were linked. | After looking at defgeneric am I right in thinking that a generic | function is "the same kind of thing" as the list of methods that a class | has in a language like C++/Java (ie some kind of look-up table that | organises the methods by specificity etc)? no. skip this comparison competely until you understand it. actively forget C++/Java and don't think about their way of doing things at all while you try to deal with CLOS methods. it's like trying to understand the French "ne pas" and trying to make it match "do not" in English. it works up to a point, but it doesn't actually work that way. | (this then explains why people suggested using defgeneric in a separate | package to define the structure) huh? where did you find this suggestion? | Sorry that I keep trying to link things to unrelated languages - I | realise they are different beasts, I'm just trying to get my bearings. you will fail to relate to other languages until you have understood each one by itself. you won't understand one language until you have ceased to want to relate to others. different languages need to be understood on their own terms. and more than anything else, make sure that you wait until you have _good_ reason to think two similar properties of two different languages are the same -- more often than not, they are very different, yet look deceptively the same. take symbols in Scheme and CL, for instance. #:Erik -- save the children: just say NO to sex with pro-lifers