| Author |
Message |
|
| cyberlync |
 Posted: Tue Oct 31, 2006 9:55 pm |
 |
|
|
User
Joined: 28 Feb 2005
Posts: 72
|
So that being the case, whats required for packages to become a first
class feature of the language? More specifically whats the path toward
this goal? I ask this not as a troll but as a somewhat concerned
member of the community.
On 10/31/06, Ulf Wiger <ulf@wiger.net> wrote:
> Den 2006-10-31 20:22:04 skrev Eric Merritt <cyberlync@gmail.com>:
>
> > So package names and module names are semantically equivalent. These
> > are both solutions to the namespace issue. The namespace problem isn't
> > that bad and we will never have the function name collision problem of
> > C. However, even module name collisions can become annoying as more
> > and more open source code becomes available. Thats actually what
> > really worries me.
>
> I agree, and that's been my main reason to support the package concept.
>
> In my(*) soon to be released application, erlhive, I rely heavily
> on both packages and parameterized modules.)
>
> (*) Mine and Joe's, to be clear.
>
> BR,
> Ulf W
> --
> Ulf Wiger
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
    
|
| xpdoka |
| Posted: Wed Nov 01, 2006 5:59 pm |
|
|
|
User
Joined: 16 Oct 2006
Posts: 52
|
Hi Eric,
> Shouldn't that debate happen then? Having this quasi
> experimental aspect of the language that some find useful
> and some don't that may or may not go away seems to be a
> problem.
I agree, although in fact the debate keeps coming back. I'll
reiterate the points I made several years ago, and then I
suppose I should put my energy into providing the
alternative solution 
Sean pointed out:
> It looks a bit like Java and is therefore not to the taste
> of many hardcore Erlang hackers.
Yes, but it's not just snobbery: I worked for years with C++
namespaces and Java packages, and they have problems that I
would not like to relive with Erlang.
The current Erlang package system confuses several issues:
- avoiding module name clashes
- grouping related modules together logically
(semantically)
- grouping related modules together physically (file
system)
NAME CLASHES
------------
Using packages to avoid name clashes has two flaws:
1) it only reduces the likelyhood of a name clash, and if
one occurs nevertheless you are back to square one;
2) it forces you to deal all the time with a problem that
may never occur, or rarely occurs.
Both of these are because the problem is being dealt with at
the wrong time. Name clashes should not be avoided before
they occur, they should be resolved if and when they occur.
SEMANTIC STRUCTURE
------------------
There is something to be said for being able to use the same
name in different contexts, being able to distinguish them
when necessary but not bother when in a given context. For
example, Graphic.Train (a graphical UI object) and
Radio.Train (representing a radio connection with a train):
it's nice to call them both Trains, and not to need to
specify Radio all the time in the rest of the Radio code.
This comes up a lot in object-oriented designs, but in
Erlang, I am not so sure. Modules don't map to
classes. Modules are already closer to what packages can be
used for from a design perspective.
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.
PHYSICAL STRUCTURE
------------------
Forcing the package structure to be mapped to a directory
structure is a real pain.
First, the directory structure becomes so much more
complex. It's not only in the editor (I am not an Emacs
newbie, and I use tags - although I haven't checked if they
work with packages yet), it's also all the rest: things you
do in the shell, scripts, makefiles, version management...
Richard O'Keefe argued that it's even a mistake to force any
mapping onto the filesystem (even module names):
http://www.erlang.org/ml-archive/erlang-questions/200309/msg00044.html
Ideally, I would like Erlang to have no files at all, like
Smalltalk. In a sense, any kind of mapping seems contrary to
this ideal. On the other hand, I suppose writing tools that
hide the filesystem is easier if the tools can make strong
assumptions about the organisation of files.
ALTERNATIVE SOLUTIONS
---------------------
The simplest way to resolve name clashes after they occur is
to rename one of the modules. Better support for automated
refactoring would make this easy, and I guess that covers
99% of the name clash situations.
Beyond that, the most elegant solutions to these issues were
pinpointed by Bertrand Meyer and are implemented in the
Eiffel language.
Regarding logical organisation, he points out that a
language's basic organisational unit (the class in Eiffel,
the module in Erlang) is itself sufficient to express
multiple, nested levels. To group several modules together
logically, use a module: it can provide a simplified, or
unified, or modified, or concatenated, or whatever, facade
for the group of related modules. I admit that this argument
is a bit stronger in Eiffel, where you can use inheritance
(including multiple inheritance without the pain). In
Erlang, you'd have to hand-code all the delegation of
function calls to the other modules. In practice though, you
rarely need to do this for all functions, and providing a
simplified front-end is enough.
Regarding name clashes, Eiffel has a system to resolve name
clashes once they occur: you can locally, in a class or a
group of classes, rename another class and use it under a
different name.
In Erlang, that would amount to being able to add a:
-rename("external/foo", bar).
attribute to a foo module to allow it to refer to another
foo module as bar, or as a compile option to allow an entire
application to use bar to refer to a foo module from another
application.
Note that this mechanism can do more than just solve name
clashes: it can be used to make code clearer when a module
name that made sense in its original context gets used in a
different context.
It has been argued that this mechanism would be difficult to
implement in Erlang:
http://www.erlang.org/ml-archive/erlang-questions/200309/msg00045.html
I find it hard to believe it would be impossible, though it
might require modifications in the runtime system.
Even if a renaming mechanism is too difficult to implement,
I don't think packages system in its current form is
satisfactory and I vote for it not to be officially adopted.
Regards,
Dominic Williams
http://www.dominicwilliams.net
----
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Wed Nov 01, 2006 6:48 pm |
|
|
|
Guest
|
On 1 Nov 2006, at 17:50, Dominic Williams wrote:
Lots of good stuff..
>
> 1) it only reduces the likelyhood of a name clash, and if
> one occurs nevertheless you are back to square one;
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'.
If a name clash helps to consolidate even 1 such project into a
single stronger code base then it has been a benefit.
>
> 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.
>
> Ideally, I would like Erlang to have no files at all, like
> Smalltalk. In a sense, any kind of mapping seems contrary to
> this ideal. On the other hand, I suppose writing tools that
> hide the filesystem is easier if the tools can make strong
> assumptions about the organisation of files.
Here I disagree. I very much like the simple mapping of 1 module == 1
file with the same name. Every layer of indirection is another thing
to distract from the difficult enough business of writing clean
elegant and correct code.
>
> Even if a renaming mechanism is too difficult to implement,
> I don't think packages system in its current form is
> satisfactory and I vote for it not to be officially adopted.
One more Vote from me. Great post!
Sean
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| cyberlync |
| Posted: Wed Nov 01, 2006 8:15 pm |
|
|
|
User
Joined: 28 Feb 2005
Posts: 72
|
I am going to try to answer some of this.
On 11/1/06, Dominic Williams
<xpdoka-dated-1162835426.9cdf0e@dominicwilliams.net> wrote:
> Hi Eric,
>
> Sean pointed out:
>
> > It looks a bit like Java and is therefore not to the taste
> > of many hardcore Erlang hackers.
>
> Yes, but it's not just snobbery: I worked for years with C++
> namespaces and Java packages, and they have problems that I
> would not like to relive with Erlang.
>
> The current Erlang package system confuses several issues:
>
> - avoiding module name clashes
>
> - grouping related modules together logically
> (semantically)
>
> - grouping related modules together physically (file
> system)
>
> NAME CLASHES
> ------------
>
> Using packages to avoid name clashes has two flaws:
>
> 1) it only reduces the likelyhood of a name clash, and if
> one occurs nevertheless you are back to square one;
Very true. However, it does does a reasonably good job of reducing the
the likelihood. As we have seen so often in the past, many times a
'Good Enough' solution that is available now is better then a perfect
solution that might be available at some point in the (distant)
future.
> 2) it forces you to deal all the time with a problem that
> may never occur, or rarely occurs.
True as well. However, packages have other benefits that reduce the
onerousness of this task.
> Both of these are because the problem is being dealt with at
> the wrong time. Name clashes should not be avoided before
> they occur, they should be resolved if and when they occur.
I would like to see an example of this that works when the name
clashes are between third party modules.
>
> SEMANTIC STRUCTURE
> ------------------
>
> There is something to be said for being able to use the same
> name in different contexts, being able to distinguish them
> when necessary but not bother when in a given context. For
> example, Graphic.Train (a graphical UI object) and
> Radio.Train (representing a radio connection with a train):
> it's nice to call them both Trains, and not to need to
> specify Radio all the time in the rest of the Radio code.
>
> This comes up a lot in object-oriented designs, but in
> Erlang, I am not so sure. Modules don't map to
> classes. Modules are already closer to what packages can be
> used for from a design perspective.
It has very little to do with classes and everything to do with
contexts. Erlang has just as much context as any other language. A
'worker_supervisor' in one application (or even one context) may be
doing a completely different thing then a 'worker_supervisor' in
another.
> 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.
True, however, this is a sociological issue not a technical one. It
also depends very much on standards a community has set. We have the
power to set our one standards on what is the right and wrong way to
name packages.
>
> 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.
Very true, once again its a sociological problem rather then a
technical one. I don't actually have a solution here except to
encourage people to not do this.
I will say that bringing up problems these types of sociological
problems isn't very helpful. Saying that users will do this or users
will do that is just hand waving. User might do that and some users
probably will, but that doesn't imply that they can't be lead in the
right direction.
> PHYSICAL STRUCTURE
> ------------------
>
> Forcing the package structure to be mapped to a directory
> structure is a real pain.
I tend to agree with you here, but I am somewhat mixed on the issue.
> First, the directory structure becomes so much more
> complex. It's not only in the editor (I am not an Emacs
> newbie, and I use tags - although I haven't checked if they
> work with packages yet), it's also all the rest: things you
> do in the shell, scripts, makefiles, version management...
>
> Richard O'Keefe argued that it's even a mistake to force any
> mapping onto the filesystem (even module names):
>
> http://www.erlang.org/ml-archive/erlang-questions/200309/msg00044.html
>
> Ideally, I would like Erlang to have no files at all, like
> Smalltalk. In a sense, any kind of mapping seems contrary to
> this ideal. On the other hand, I suppose writing tools that
> hide the filesystem is easier if the tools can make strong
> assumptions about the organisation of files.
I have to disagree with you here. The filesystem is the lingua franca
of all developement releated tools. Editors, version control systems,
differs, etc all speak to each other via the filesystem. Once you
remove the filesystem you remove the ability to use all of these other
systems and you end up reimplenting poor copies of them your your
environments world. This is an old old argument that has been rehashed
over and over again in the various lists. Its not worth rehashing
here. Suffice it to say that modules are currently intrinsically tied
to the filesystem. This is unlikely to change anytime soon so
continuing the trend shouldn't be an issue.
> ALTERNATIVE SOLUTIONS
> ---------------------
>
> The simplest way to resolve name clashes after they occur is
> to rename one of the modules. Better support for automated
> refactoring would make this easy, and I guess that covers
> 99% of the name clash situations.
This works well only if you control the entire code base. If I pull
module A from one open source project and module B from another I
don't want to change anything in module A or B. Touching files in
either invalidates all the tests that may have been run and it gives
me a local version that I now have to maintain. Neither of these
things are acceptable.
>
[snip good arguments for an eiffelish approach]
There are any number of very large problems with this approach in
erlang. Registered proc names alone would make this difficult and Vlad
sites quite a few more issues in his response.
In any case, all of this is blue sky and would take a huge amount of
effort on the part of the implementors and change the semantics of the
language to some extent for the users. Given the resources Ericsson
devotes to Erlang this might have a chance of happening sometime in
the distant future. Packages are available now and the work. This is
the pragmatic approach that Erlang has always taken there isn't any
reason not to take this approach again.
> Even if a renaming mechanism is too difficult to implement,
> I don't think packages system in its current form is
> satisfactory and I vote for it not to be officially adopted.
>
> Regards,
>
> Dominic Williams
> http://www.dominicwilliams.net
>
> ----
>
>
>
>
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| cyberlync |
| Posted: Wed Nov 01, 2006 8:19 pm |
|
|
|
User
Joined: 28 Feb 2005
Posts: 72
|
On 11/1/06, Sean Hinde <sean.hinde@gmail.com> 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.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 02, 2006 1:46 am |
|
|
|
Guest
|
"Eric Merritt" <cyberlync@gmail.com> praised packages:
Package names offer a well understood and well tested solution
to this problem. They are even in the language right now, but
their unsupported (going away any time) status makes them
unusable.
Package names may be well understood, but one of the things we understand
about them is that they are wrong, as in "inside-out, back-to-front, and
going away from you on the other side" (Goon Show quote).
What do I mean?
Let's take a tiny example where we have a "master" module 'arnold'
and some supporting modules 'betty' and 'cody'. What we really want
to do is to wrap them up somehow and expose onle 'arnold':
-flotilla(arnold).
-module(arnold, "src/arnold.erl").
-module(betty, "src/betty.erl").
-module(cody, "src/cody.erl").
-export(arnold, [start/0,serve/1,stop/0]).
>From the outside, this flotilla looks like a single module exporting
some functions. On the inside, arnold, betty, and cody can refer to
each other directly by simple names. They can also refer to "pervasive"
modules from Erlang/OTP by simple names.
What happens if we use Java-style package names?
First, we have to choose a single GLOBALLY usable package name.
For example, I might have to use
nz.ac.otago.cs.ok.arnold
nz.ac.otago.cs.ok.betty
nz.ac.otago.cs.ok.cody
and now the modules have to refer to each other by these complex names.
They don't have to mention these names repeatedly (given the preprocessor,
that's obvious), but they do have to mention the prefix at least once.
Now we have a maintenance problem and a forgery problem.
The forgery problem is that nothing actually stops anyone using any
module name they like. There is no REAL difference between
nz.ac.otago.cs.ok.arnold and nz_ac_otago_cs_ok_arnold; one uses dots
and the other uses underscores. Big deal. Someone else decides to
use nz.ac.otago.cs.ok for some modules? Just what is there to stop
them? There is NOTHING that can stop someone reusing one of my dotted
module names for something else. Just as any Erlang programmer anywhere
can use nz_ac_otago_cs_ok_arnold, so any Erlang programmer anywhere can
use nz.ac.otago.cs.ok.arnold.
The maintenance problem is that if I want to copy some modules into
another package, I have to hunt down and rename all the dotted names.
Of course that's true with underscore prefixes as well; the point is
that dotted names fail to provide any advantage here.
Basically, there are three kinds of module names we want to use:
- module names in our own application/flotilla/cluster.
These names need to be RELATIVE, so that the entire thing can
be moved around with at most one change in one file.
- names for modules provided by Erlang/OTP itself.
These names are very common and need to be short, but we don't
want new names added here to conflict with our own names.
- names for other applications/flotillas/clusters.
For these we typically need some kind of ABSOLUTE name.
The problem with the present Erlang language is that there is a single
global name space for modules. The fundamental problem with package names
is that they don't change that: there is still a single global name space
for modules, except now module names can contain dots as well as underscores.
Big deal.
No, what we need to do is to reify module name spaces and allow more than
one of them. They should be actual run time data structures that can be
explored.
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 02, 2006 6:01 pm |
|
|
|
Guest
|
On 02/11/06, Richard A. O'Keefe <ok@cs.otago.ac.nz (ok@cs.otago.ac.nz)> wrote:Quote: "Eric Merritt" <cyberlync@gmail.com (cyberlync@gmail.com)> praised packages:
|
|
|
| Back to top |
|
| Guest |
| Posted: Thu Nov 02, 2006 8:25 pm |
|
|
|
Guest
|
On 11/2/06, Chandru <chandrashekhar.mullaparthi@gmail.com> wrote:
>
> I agree. Please let's not have packages. They are so ugly. I hated them when
> I first saw them in Java and it still feels the same. We once had one of our
> module names clash with one of OTP's module names. We renamed our module and
> the problem disappeared. This is once in 7 years. As Dominic Williams said
> earlier, they force you to deal with a problem every day which only happens
> once in a blue moon.
I also agree. Packages are pretty in a way, but they're a heavyweight
solution to a simple problem.
I would much rather see some effort put into cleaning up the existing
libraries. Get rid of all the pre-fun functions that use "apply."
Add some obviously missing functions like revmap. Etc.
James
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| axel |
| Posted: Fri Nov 03, 2006 6:29 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
On 2006-11-02 18:51, Chandru wrote:
...deleted
> one of our module names clash with one of OTP's module names. We renamed
> our module and the problem disappeared. This is once in 7 years. As
otp is in the standard distribution. packages will help reducing module
name clashes between third party products. the kind where A and B spend
7 years developing, and C wants to use both their products.
if possible to adopt to erlng, the eiffel solution is better. imho.
bengt
--
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| axel |
| Posted: Fri Nov 03, 2006 6:36 am |
|
|
|
User
Joined: 03 Mar 2005
Posts: 271
|
On 2006-11-02 21:19, James Hague wrote:
> On 11/2/06, Chandru <chandrashekhar.mullaparthi@gmail.com> wrote:
>> I agree. Please let's not have packages. They are so ugly. I hated them when
...deleted
> I also agree. Packages are pretty in a way, but they're a heavyweight
> solution to a simple problem.
>
> I would much rather see some effort put into cleaning up the existing
> libraries. Get rid of all the pre-fun functions that use "apply."
would it be correct to use ''ironic'' to describe the fact that the only
effort (that i know of), to clean up the existing libraries, uses packages?
bengt
--
EPO guidelines 1978: "If the contribution to the known art resides
solely in a computer program then the subject matter is not
patentable in whatever manner it may be presented in the claims."
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| xpdoka |
| Posted: Fri Nov 03, 2006 7:23 am |
|
|
|
User
Joined: 16 Oct 2006
Posts: 52
|
|
| Back to top |
|
| Guest |
| Posted: Fri Nov 03, 2006 5:56 pm |
|
|
|
Guest
|
On 11/3/06, Bengt Kleberg <bengt.kleberg@ericsson.com> wrote:
>
> would it be correct to use ''ironic'' to describe the fact that the only
> effort (that i know of), to clean up the existing libraries, uses packages?
Yes, I know. But obviously packages aren't going over all that well
or they'd be standard by now.
James
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Fri Nov 03, 2006 6:09 pm |
|
|
|
Guest
|
On 3 Nov 2006, at 06:28, Bengt Kleberg wrote:
> On 2006-11-02 21:19, James Hague wrote:
>> On 11/2/06, Chandru <chandrashekhar.mullaparthi@gmail.com> wrote:
>>> I agree. Please let's not have packages. They are so ugly. I
>>> hated them when
>
> ...deleted
>> I also agree. Packages are pretty in a way, but they're a
>> heavyweight
>> solution to a simple problem.
>>
>> I would much rather see some effort put into cleaning up the existing
>> libraries. Get rid of all the pre-fun functions that use "apply."
>
> would it be correct to use ''ironic'' to describe the fact that the
> only
> effort (that i know of), to clean up the existing libraries, uses
> packages?
The irony is slightly reduced by the fact that the cleanup was being
done by the implementor of packages
Sean
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| uwiger |
| Posted: Fri Nov 03, 2006 7:00 pm |
|
|
|
User
Joined: 03 Jul 2006
Posts: 604
Location: Sweden
|
James Hague wrote:
>
> But obviously packages aren't going over all
> that well or they'd be standard by now.
That could be the case, but it's sort of a
chicken-and-egg problem too. Bengt obviously
likes packages, but doesn't use them because
it's an experimental feature.
Obviously, a many people aren't even aware
of the existence of packages, since they aren't
documented (at least not in the OTP documentation.)
Also, we don't have a terrible namespace problem
in Erlang, partly because not that many people
develop reusable components in Erlang ... yet. (:
It could be argued that we should deal with the
problem once it's obviously a problem. OTOH, when
it's obviously a problem, changing the language is
also obviously going to be more difficult than it
is today.
ROK's 'flotilla' concept also hasn't been adopted.
Does that mean it's obviuosly a bad idea? What about
abstract patterns, or structs? They've certainly been
debated long enough, but are still not in the
language. Does that mean they shouldn't be?
(I have to practice writing 'obviously', because I
mistype it every time...)
BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
| xpdoka |
| Posted: Fri Nov 03, 2006 8:11 pm |
|
|
|
User
Joined: 16 Oct 2006
Posts: 52
|
Hi Eric,
> True, however, this is a sociological issue not a
> technical one. It also depends very much on standards a
> community has set. We have the power to set our one
> standards on what is the right and wrong way to name
> packages.
> [...]
> I will say that bringing up problems these types of
> sociological problems isn't very helpful. Saying that
> users will do this or users will do that is just hand
> waving. User might do that and some users probably will,
> but that doesn't imply that they can't be lead in the
> right direction.
Compared to some other language communities I have known,
this one is actually rather weak on community
standards. I'll just offer three examples:
- naming (camel case vs. underscore)
- returning tagged values vs. throwing
- using OTP or not
The standard libraries themselves are sadly lacking in
homogoneity. There is no consistent naming system, no
consistent ordering of arguments, various strategies for
error handling...
Also, the more Erlang spreads into open source, web
development and so on (and this prospect has been offered as
an argument for needing a solution to name clashes...), the
more likely it becomes that whatever standards we do have
become diluted.
However, out of interest and to see whether there would be a
consensus, what would those standards of right and wrong
ways of naming packages be?
>> The simplest way to resolve name clashes after they occur
>> is to rename one of the modules. Better support for
>> automated refactoring would make this easy, and I guess
>> that covers 99% of the name clash situations.
>
> This works well only if you control the entire code
> base. If I pull module A from one open source project and
> module B from another I don't want to change anything in
> module A or B. Touching files in either invalidates all
> the tests that may have been run and it gives me a local
> version that I now have to maintain. Neither of these
> things are acceptable.
How about a parse transform?
Regards,
Dominic Williams
http://www.dominicwilliams.net
----
_______________________________________________
erlang-questions mailing list
erlang-questions@erlang.org
http://www.erlang.org/mailman/listinfo/erlang-questions
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
