[erlang-questions] packages (was: newbie: why c.erl is special?)

David Mercer dmercer@REDACTED
Fri Mar 7 18:18:24 CET 2008

You know, I sent this in jest, but now that I think about it, it's not such
a bad idea.  You can define a macro giving a better name for the module so
you don't have to keep using the GUID.  Howzat?


-define(stringlib, 'a613fd8b-647c-4b1a-9f4c-810f0b99993a')

. . .






From: David Mercer [mailto:dmercer@REDACTED] 
Sent: Friday, March 07, 2008 11:09
To: 'erlang-questions'
Subject: RE: [erlang-questions] packages (was: newbie: why c.erl is


Maybe we should name all our modules with a GUID.  That would reduce the
likelihood of module name clashes down close to zero.









From: erlang-questions-bounces@REDACTED
[mailto:erlang-questions-bounces@REDACTED] On Behalf Of Robert Virding
Sent: Thursday, March 06, 2008 17:57
To: Steve Vinoski
Cc: erlang-questions
Subject: Re: [erlang-questions] packages (was: newbie: why c.erl is


On 06/03/2008, Steve Vinoski <vinoski@REDACTED> wrote:

On 3/6/08, Sean Hinde <sean.hinde@REDACTED> wrote:
>  One of the worst aspects of this would be the endless traversing up
>  and down interminable directory hierarchies. Soon we would need a full
>  IDE just to help us find the definition of a module in the filesystem.

YES! I was about to point out the same thing, and I'm very glad to
know I'm not alone in my thinking. Java's abuse of the filesystem in
this manner is very annoying, for example, and pushing Erlang to that
model would be a huge mistake IMO.

One of our original goals, which is seldom mentioned today, was that we
wanted to keep the language *simple*! Then many programmers in Ericsson, who
were out potential users, were not very experienced and not well trained in
the art/science of programming. This is one reason why features considered
standard were added later. This may not have been a good design decision but
it did result in a small simple base language. I have read on the net
discussions about designing languages for the masses, or not.

And, whatever its warts, a flat module system is easy to comprehend. If you
call module foo there is only one module foo to which it can refer,
irrespective of from where it is called. And you can always use naming
conventions to handle the case of many modules in an application or



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080307/2bf0a081/attachment.htm>

More information about the erlang-questions mailing list