Package extensions usage

Antoniotti Marco antoniotti.marco at disco.unimib.it
Wed Dec 30 10:59:24 UTC 2015


All this discussion is fine.

FWIW I kinda like the idea of hierarchical packages although I have not really have had much use for them up to now; and, having dealt with Java, I know how easy they get out of hand.  Package-local nicknames would be very nice indeed, and a must once you have hierarchical packages, but I fear that anything that required too much developers’ work (beyond SBCL) leaves the time it finds.

Having said that, I move that a *spec* is *much* more important than an *implementation*.  At a minimum to gather in one place all the bits and pieces that the different implementations now have.  Writing things down (in CLHS or C standard style) forces one to actually think very well about what is desirable and/or achievable; not to mention the devilish details.

Happy New Year
—
MA






> On Dec 30, 2015, at 12:42 , Pascal Costanza <pc at p-cos.net> wrote:
> 
> 
>> On 30 Dec 2015, at 03:12, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>> 
>> On 30/12/15 02:25, Pascal Costanza wrote:
>>> Hi,
>>> 
>>> 1) I believe package-local nicknames are very useful. Being able to use abbreviations and avoiding conflict between nicknames from the use site are just good ideas.
>>> 
>>> 2) I don’t believe hierarchical package names are useful. That’s a Javaism which just makes things too complicated (especially if they then also are reflected by the directory hierarchy - beurk ;).
>> You're saying that because there are only 1279 systems in quicklisp so it's still manageable as a flat list.  But wait a little with tens or hundreds more systems and packages!
> 
> No, I’m saying this although there are already 1279 systems in quicklisp. I actually had to rename a library twice because my name choices clashed with existing library names, so I understand the problem that people want to solve. I nevertheless stand by my statement. (I have sufficient experience with Java to know that this doesn’t help much.)
> 
>> Probably, you've never worked with a big source base with a directory hierarchy didn't match the naming scheme.
> 
> You shouldn’t make too many assumptions about other people’s experiences.
> 
>>> Also, I agree with Kenny that splitting libraries into too fine-grained small little packages is not a good recipe for organizing your projects. Lisp packages want to be big, and there is no major disadvantage in doing so, and I fear that hierarchical package names encourage unnecessary fine-grained splitting. That just creates visibility problems, and distract from solving /actual/ problems.
>> Agreed.
>> 
>>> Basing package names on domain names provides the illusion that you have unique names, but domain names come and go, companies change owners, repositories move to different hosting servers, etc., etc., so they are not as stable as one might think. If people use sufficiently long package names that can then be renamed locally using package-local nicknames, that’s sufficient, IMHO.
>> 
>> Oh, you're right. Now I see the light.  I will therefore rename my com.informatimago.* package into 2915BB3ECC3D45029DBF41BD48508E2E.*
>> And let's not talk about the 3 or 4 different CLON packages we have...
> 
> I don’t strongly object to hierarchical package names. If that’s what the community wants, I’m fine with it. Package-local nicknames are more important, though. I especially would be unhappy if hierarchical package names were adopted, but package-local nicknames weren’t.
> 
> All IMHO, YMMV, etc., etc.
> 
> ;)
> 
> Pascal
> 
> --
> Pascal Costanza
> The views expressed in this email are my own, and not those of my employer.
> 
> 
> 
> 

--
Marco Antoniotti, Associate Professor			tel.	+39 - 02 64 48 79 01
DISCo, Università Milano Bicocca U14 2043		http://bimib.disco.unimib.it
Viale Sarca 336
I-20126 Milan (MI) ITALY

Please check: http://ceac.lakecomoschool.org

Please note that I am not checking my Spam-box anymore.
Please do not forward this email without asking me first.







More information about the pro mailing list