[Prev][Next][Index][Thread]

Re: Some Dylan improvements

In article <38E1B578.BC05AD4E@cup.hp.com>, eric_gouriou@pobox.com 
wrote:

>  Hello,
> 
>  Following the module/library discussion, I would expose to the
> community some ideas I have on how Dylan could be improved.
> 
>  My goal is to evaluate the amount of support each one of those
> ideas would find among the community. I certainly do not expect
> to see any of those changes appearing in FD 2.0 (or even 2.x),
> nor do I expect GD to implement those before an agreement is
> reached.
> 
>  Proposed changes (more comments below):
> A) specify a naming convention for libraries

I've only recently actually started programming in Dylan, so I'm not an 
"elder statesman" by any means, and plus it's late, but I'll toss my 2? 
in anyway...

A naming convention of the sort Java has is A Bad Thing.  Yes, I'm 
willing to put that in caps.  I don't do it lightly.  It is bad in 
theory, and it is bad in practice.  Such a naming convention has only 
two 'advantages':  reducing the chances of name collision, and 
classifying functionality.

Dylan already provides good name-collision protection in the form of 
modules.  The only name collisions left are those between libraries, an 
easier problem since so few libraries make up a program.  But what is 
the best solution to this problem?  Is it really to lengthen the name?  
Maybe, but I think some GUID solution would be better, and I know it 
would be better than what Java uses.  The thing is, we don't know what 
the best solution is.  Leaving it up to the implementation -- as the DRM 
says -- gives us some flexibility to adapt, to scale, to evolve 
techniques.

Java uses two techniques to reduce collisions: corporate and personal 
names, and functionality.

The former is clearly a hack.  Look around, people.  Companies break up, 
repurpose, change ownership, rise, and fall -- any one of which can 
result in a name change.  People change their names, or take things they 
write and sell them or start a business around them -- and can no longer 
lay claim to their libraries.  So once a library is named, it will keep 
the name forever, even if it is no longer relevant or accurate...or 
maybe each time ownership changes, the name will change, and it well 
seem like a completely different library, even though it's not...or, 
even worse, maybe companies will separately rename a identical libraries 
that both licensed from a third party.  The point of this rather long 
paragraph is to show the ephemeral and inherently nonstandard nature of 
real-world names.  They shouldn't be used where it matters.

Java also divvies up namespace by functionality.  Dylan could do that, 
but there are questions.  On what basis should functions be divided?  
Who decides what the divisions are?  How granular should the divisions 
be?  Different problem domains require different organization, and it's 
arrogant and counter-productive to fix an organizational scheme for all 
domains.

Grouping libraries by functionality wouldn't reduce collisions by much, 
if at all, anyway.  Libraries are naturally named according to what they 
do.  Another sort of division is needed -- but obviously I don't think 
company names are appropriate.

So, basically, I say leave library naming and management up to the 
programmers and implementations.  Let 'em do whatever makes sense on a 
case-by-case basis.  They are Johnny-on-the-spot.  Think of it as a sort 
of late binding technique -- and we all know what the advantages of late 
binding are, right?

-- Dustin Voss
Follow-Ups: References: