[cl-muproc-devel] Some suggestions

[Jochen Schmidt]

Am 17.05.2006 um 20:23 schrieb Klaus Harbo:
> Package names as short as MU or M moved the name space clutter into  
> the package name space instead, so I see some problems following  
> that particular path (also, since I work for a company called Mu, I  
> think we'll find the name MU less than descriptive!).  We'll run  
> out of single-letter package names very quickly indeed.
>
> I do not want to rule out the idea of getting rid of the muproc-  
> prefix from the names of the exported symbols in cl-muproc; at the  
> same time it does not strike me as a very high priority item.   
> Also, it seems to me that such a change would mean that it may be  
> difficult to import muproc symbols into user packages, due to -  
> potentially - name clashes.  This would mean using 'muproc:send'  
> instead of 'muproc-send', so I wonder, then, what we have  
> accomplished?  (Unless if we choose to go with Jochen's supershort  
> package names, which I do not think is a great idea).

I may have explained my point a bit to fuzzy - I did not mean to  
suggest to rename the package to something very short like M or MU -  
better make it longer DK.MU.MUPROC or whatever to make it unique.  
Then use (in-package :dk.mu.muproc) everywhere in CL-MUPROC. A _user_  
of CL-MUPROC can then decide to:

1) Import all exported symbols of CL-MUPROC using USE-PACKAGE in his  
application package
2) Import only a small selection of symbols of CL-MUPROC in his  
application package
3) Import all but shadow some CL-MUPROC or other symbols
4) Just use DK.MU.MUPROC:SEND or perhaps the provided nickname  
MUPROC:SEND.
5) Define his own nickname MU:SEND or ERL:SEND or M:SEND whatever he  
wants in the scope of his application
6) Use something like CL-PACKAGE-ALIASES (http://www.cliki.net/cl- 
package-aliases) or hierarchical packages to create short package- 
name aliases within a particular package.

So: using packages provides a choice that is unavailable if one uses  
hardcoded prefixes.

I hope this made the intention behind my suggestion a bit clearer,

Jochen