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 <p...@p-cos.net> wrote:
> 
> 
>> On 30 Dec 2015, at 03:12, Pascal J. Bourguignon <p...@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.





Reply via email to