freenode/#clim - IRC Chatlog
Search
3:54:27
jackdaniel
a short screencast showing integration of the interactor/listener with the inspector on genera: https://vimeo.com/536080282
5:07:57
lukego
Hey I have a big package MYAPP that will be doing CLIM things. So far I've made a separate package MYAPP-CLIM that uses :CLIM-LISP instead of :COMMON-LISP. Trouble is though that I want to access a lot of internal APIs within MYAPP so the code has a lot of MYAPP::X accesses that feel a bit dirty. How do other applications deal with this? Export lots of stuff? Or put use CLIM-LISP from the main package?
5:27:46
pjb
lukego: well, the later, but the best would be to have lose coupling between your app and clim…
5:29:07
lukego
Yeah but that's not really convenient when hacking away experimentally or writing ad-hoc code to debug internal stuff. Feels more like an optimal solution would be for MYAPP-UI to be able to import internal symbols of MYAPP in those cases.
5:30:08
lukego
but yeah thanks for the sanity check! I guess the trade-offs are more or less the way I imagined them
5:31:20
pjb
lukego: well, you can import the stuff dynamically, or use "conduit" packages. https://github.com/tfeb/conduit-packages
5:32:28
pjb
(do-symbols (s "MYAPP") (import s)) ; this is violent, all local symbols will be imported…
5:33:22
pjb
lukego: what you could do is to define a defpackage MYAPP-EXPORT-ALL with (:export . #.(let (e) (do-symbols (s "MYAPP" e) (push (symbol-name s) e))))
5:33:41
pjb
then you can just load one package definition or the other, depending on the circumstance.
5:43:01
jackdaniel
also for biggish packages I provide two packages: api package that only exports, and (defpackage foo.impl (:use #:clim-lisp #:foo)) where the latter doesn't export anything