🚀 go-pugleaf

In article <LANNING.90Dec5104344@spade.parc.xerox.com> 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