Path: utzoo!attcan!uunet!peregrine!elroy.jpl.nasa.gov!sdd.hp.com!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.lang.clos Subject: Re: Naming: clos generics vs common lisp fns Message-ID: <1990Dec5.232403.6954@Think.COM> Date: 5 Dec 90 23:24:03 GMT References: Sender: news@Think.COM Distribution: comp Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 31 In article lanning@parc.xerox.com (Stan Lanning) writes: >With that said, you may still decide that you are willing to pay the >price because of some other benefit(s). In that case, it's easy to make >AREF generic in your package, as long as your AREF isn't the system's >AREF: This is mostly a valid point, but it doesn't address one aspect. If the system AREF (along with all the other array operations) were generic, then you could pass your pseudo-array object to any function that expects an array and it would automatically invoke your methods. For instance, you could pass objects of your type to the sequence functions, or to functions in a third-party package. If you're forced to shadow the function name then it's no different from giving it a totally different name. Shadowing a standard function name is more likely to confuse a future reader or editor of the code. The reason this isn't done, though (beside the performance aspects that you mentioned), is that it requires specifying the complete protocol that such objects must support. Notice the parenthetical "along with all the other array operations" comment above, as it is all-important. It's not enough for AREF to be generic, because a function that calls AREF is likely to call ARRAY-DIMENSIONS or ARRAY-RANK, and possibly ADJUSTABLE-ARRAY-P or ARRAY-HAS-FILL-POINTER-P (and if either of these return T, it might call ADJUST-ARRAY or FILL-POINTER, respectively). Specifying protocols completely is *hard* (the CLOS committee has been working on the meta-object protocol for at least three years). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar