This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: define-alias question
- From: Jamison Hope <jrh at theptrgroup dot com>
- To: "kawa at sourceware dot org list" <kawa at sourceware dot org>
- Date: Thu, 18 Jul 2013 18:50:03 -0400
- Subject: Re: define-alias question
- References: <CAOTvmokJvFFYkeCJPvD-VTmZNQ-n=S1v7AdyyTwyjDUQdbj3Vw at mail dot gmail dot com> <51E7900F dot 7060301 at bothner dot com>
On Jul 18, 2013, at 2:49 AM, Per Bothner <per@bothner.com> wrote:
> On 07/17/2013 07:29 PM, Matthieu Vachon wrote:
>> I think this should not happen because in my opinion, alias should be
>> private to the module where they were defined. I see not much points
>> in making them exportable other then creating conflicts. Of course, I
>> could oversee some really valid use-cases that would involve exporting
>> aliases.
>
> For consistency, I think it would be possible to export an alias.
> However, perhaps it would only be exported if explicitly specified
> as exported. That would be an incompatible language change.
> What do people think of that?
I have a few modules which do little more than create and export aliases, to cut down on duplicated alias definitions at the tops of Kawa application scripts (most of them just strip the packages off of FQCNs, a la Java's import). Something like:
(import (com example commonly_used_classes))
;; Now I can do
(define p ::Point3d (Point3d 1 2 3))
;; instead of
(define p ::javax.vecmath.Point3d (javax.vecmath.Point3d 1 2 3))
I have no problem with requiring an export statement, in fact I think I already do that in most of my code. But I would be annoyed if it were impossible to export aliases.
-Jamie
--
Jamison Hope
The PTR Group
www.theptrgroup.com