[erlang-questions] Package Support/Use

[Eric Merritt]

On 11/1/06, Sean Hinde <sean.hinde@REDACTED> wrote:
>
> On 1 Nov 2006, at 17:50, Dominic Williams wrote:
>
> Lots of good stuff..
>
>
> Absolutely. I would even go as far as to argue that it is a hidden
> benefit for community projects to have a single flat namespace. The
> Erlang world does not need 3 projects with the module name
> 'http_client', or 2 projects with the module 'ssh_cm'.

This is a pretty arbitrary statement. I am not sure it holds water.
There is nothing wrong with different projects implementing the same
thing. We already have two http client applications and two web
servers, etc. It so happens that the libs shipped with otp are well
known so name clashes weren't an issue. However, as the foss community
grows it becomes very likely that projects may not know about one
another or worse come up with the same name for different
functionality. Its not hard to see that happening.


> If a name clash helps to consolidate even 1 such project into a
> single stronger code base then it has been a benefit.

No it hasn't. The main problem is that these clashes aren't
necessarily visible during creation of the projects. The become
visible only after some third party user tries to use them together.
Once that happens the third party user has very little recourse in how
he moves forward.

> >
> > In any case, the name clash avoidance situation comes and
> > spoils this otherwise legitimate use of packages, because:
> >
> > 1) to further reduce the chance of clash, no one resists the
> >    temptation of introducing additional levels (company
> >    name, product, ...) which have NO value in terms of
> >    describing the design and NEGATIVE value in terms of
> >    making the code clearer.
> >
> > 2) because packages encourage you to think about this kind
> >    of structure too soon, the package organisation is
> >    usually too complex and often does not even map to the
> >    code dependencies.
>
> Great points. Totally agree. It is hard enough to get into an
> existing large project without heavily misleading historical
> organisational cruft.

 Organizational cruft always exists. Providing deeper directory
structure isn't going to add significantly to it.