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 |