Re: namespaces, goops, etc.

[Michael Livshin]

"Lars J. Aas" <address@hidden> writes:

> I've noticed I can use the module system's "define-public" inside functions
> and get internal definitions exported to the toplevel namespace.
> 
>   (define (some-function)
>     (define (some-internal-function)
>       (define-public (some-internal-internal-function)
>         (display "some-internal-internal-function\n")))
>     (some-internal-function))
> 
>   (some-function)
>   (some-internal-internal-function)
> 
> I'm curious on whether this is just a side-effect of the implementation of
> the module system, or if it is supposed to work like this and people can take
> advantage of it?

you probably could take something of it, but I wouldn't call it
advantage ;)

seriously, `define-public', if used on an already `define'ed name, is
pretty sick.  it conflates definition and visibility setting.

there's nothing wrong with `define-public' as is, but using it just to
change visibility of an existing object should be prohibited, IMHO.

(and using it in any place other than the top level should be
prohibited also -- this way it's incompatible with internal define).

> Another thing I've noticed is that generic goops methods has to be defined
> in the toplevel namespace.  Was there a reason for this design decision, other
> than perhaps making the goops module easier to implement (global variables and
> stuff?)?  Just wondering - it's not a feature I miss or anything, although I
> can imagine it could be useful with local generic methods in certain
> circumstances...

this design decision surely looks right to me.  except you are
speaking specifically about `define-method', because you can add and
remove methods anytime, by more "imperative" means.

-- 
Non-determinism means never having to say you're wrong.