This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: define-namespace patch
Per Bothner <per@bothner.com> wrote:
> I guess it's reasonable to allow <cname> as a convenient shorthard for
> "class:cname". However, the implementation isn't right.
That's no surprise! I can't see all the subtleties of the system. Or
at least not yet :-).
> However, the implementation isn't right. You're doing the re-mapping
> at reader-time, but it should be done later at name resolution time.
Aha - that makes sense. Can you point me at the right place to make the
change?
> Adding define-private-namespace raises the question: why don't we have
> private versions of all the other define forms: define-private-syntax,
> define-private-alias, etc.
>
> Yes, I suspect most uses of define-namespace should be private, but
> there is the issue of controlling language bloat.
The analogy is with the define-private form. Sure you can use
module-export, but as you say most uses of define-namespace (for me at
least) should be private. The normal case is I have a couple dozen
procedures and one or two define-namespaces that are being used just for
implementation of the procedures.
My goal is very pragmatic - how can we use Kawa to write real programs
easily, powerfully, consistently, and elegantly. I hear what you are
saying about define-private-namespace and how it doesn't seem consistent
with the rest of Kawa. I agree. The lazy side of me likes
define-private-namespace because it is less work for me.
One solution (which seems ugly to me) would be to not issue a duplicate
definition warning when two namespace with the same value where
encountered.
Or maybe the right long term goal is to have a different way of calling
Java code.
Regards,
Chris Dean