CLIM mail archive


Re: CLIM 2.0, pane names

> Whether or not it is prohibited, it is generally unwise to add (most)
> global attributes to symbols inherited from the common-lisp package,
> such as a global value, or what is equivalent, a symbol-macro.
> It stands a good chance of colliding with another program's (possibly
> accidental) use of that symbol.

A symbol macro is not a global attribute.  Portable programs cannot make global variable, 
function, ... definitions for exported CL symbols, but they may establish lexical bindings, 
where such bindings cannot shadow a defined global binding.

> Then, there was the time I decided to
>   (defvar NUMBER <something>)
> You can go a long time without anything actually _breaking_, before you
> notice how dumb it is.

Right.  This code is in error.

The problem I was responding to however, was that the compiler for some implementation was 
complaining about valid *lexical* bindings.

Note however, that it may or may not be that its a bad idea to use exported CL names for 
these CLIM entities for the same reasons.  I don't know enough about CLIM toknow the scope of 
the names being defined as CLIM entities.


Main Index | Thread Index