[Bese-devel] Some trivial changes

burban at opopop.net burban at opopop.net
Sun May 16 22:28:55 UTC 2010


Anton Rizov <anton.rizov at gmail.com> writes:

> Hi,
> 
> Before anything else I have a "management" question. As I'll be doing
> (mostly trivial for now) changes so it would be useful to know about the
> policy here. What do you prefer to ask/discuss on this list before
> changing anything or directly send patches?
> 
> This time I'll ask:
> 
> * Is there any reason in-application is not exported?
> 
>   In protocol.lisp there is a macro in-application but it is not
>   exported. IMHO it could be useful in client code as it will
>   eliminate the need to specify :application argument in
>   defentry-point.
> 
>   Any objections about exporting it?
> 
> * Is *ucw-applications-directory* in vars.lisp needed?
> 
>   I don't think this variable is actually used. Any reason to keep it?
> 
> * Is *ucw-systems* in vars.lisp needed?
> 
>   Same as *ucw-applications-directory*

IMHO, in-application, *ucw-applications-directory* and *ucw-systems*
are not used elsewhere, so could be suppressed. *ucw-applications* is
used in create-server, so should be kept to not break existing code.

> * How about changing default value fo create-server :application argument?
> 
> - (applications *ucw-applications*)
> + (applications (or *ucw-applications* '(*default-application*))

What if *default-application* stays nil?
 
>   So than one could write:
> 
>   (in-application (make-instance 'demo-application))
> 
>   (create-server)
> 
>   rather than
> 
>   (create-server :applications '(*default-application*))

I prefer the later, as it clearly shows what applications are handled
by what server.

>   Or maybe changing in-application
>   (pushnew *default-application* *ucw-applications*)

Another concern I have with 1 line defmacro such as in-application is
that in most cases they don't bring clarity and simplification to the
code; at the contrary, in-application hides that there is a side effect.

Sincerely.

-- 

B. Urban




More information about the bese-devel mailing list