« Return to Thread: Time to update programming rules?
Re: Time to update programming rules?
by Edwin Fine
::
Rate this Message:
Thanks for repeating yourself. I didn't know you had posted about it before, and sometimes I don't even think of searching the lists, mea culpa.
I empathize with your pain at having to hack modules with namespace/directory changes. I have done this too many times (actually, once is too many times) with Java to develop a serious allergy to its namespace mechanism. Then again, if you are amenable to IDEs, Eclipse allows you to refactor Java quite painlessly, including moving between namespaces. Of course, that won't stop namespace changes from breaking someone else's existing code that uses the old namespace. I will look into C/Mesa and Lace - they sound interesting.
The worse problem is the ability to have two modules with different names to refer to the same module. That's a showstopper.
I am reminded of another namespace abomination, namely the addition of namespaces to XML. XML names were originally allowed to contain the colon character. This became a way to retrofit namespaces to XML without breaking backward compatibility (much).
It seems that much evil is done in many spheres to retain backward compatibility, especially in the face of temporal or market pressures - remember the segmented x86 architecture? I wonder how many people on this list were forced to work with the various x86 compiler memory models (IIRC, tiny, small, compact, medium, large, and huge). I was praying that the 68000 would win. Oh, the horror, the horror...
I empathize with your pain at having to hack modules with namespace/directory changes. I have done this too many times (actually, once is too many times) with Java to develop a serious allergy to its namespace mechanism. Then again, if you are amenable to IDEs, Eclipse allows you to refactor Java quite painlessly, including moving between namespaces. Of course, that won't stop namespace changes from breaking someone else's existing code that uses the old namespace. I will look into C/Mesa and Lace - they sound interesting.
The worse problem is the ability to have two modules with different names to refer to the same module. That's a showstopper.
I am reminded of another namespace abomination, namely the addition of namespaces to XML. XML names were originally allowed to contain the colon character. This became a way to retrofit namespaces to XML without breaking backward compatibility (much).
It seems that much evil is done in many spheres to retain backward compatibility, especially in the face of temporal or market pressures - remember the segmented x86 architecture? I wonder how many people on this list were forced to work with the various x86 compiler memory models (IIRC, tiny, small, compact, medium, large, and huge). I was praying that the 68000 would win. Oh, the horror, the horror...
On Thu, Sep 4, 2008 at 11:14 PM, Richard A. O'Keefe <ok@...> wrote:
On 5 Sep 2008, at 2:55 pm, Edwin Fine wrote:
Richard,
Please will you clarify what you mean by
(a) we should not use them because they are inside out
I have discussed this at length in this mailing list.Yes.
Do you mean, we should not use these facilities at all, ever, because the design is badly flawed,
One fundamental issue is that dotted names are just that:
a *FLAT* module name space that just happens to allow dots
in identifiers. Since Erlang already allows @ signs in
identifiers, if we had wanted to use names like
mnesia@CORBA@connector@impl
we could have and can still. (Think of the "@" signs as
"fat dots".) Allowing dots in identifiers doesn't, in
principle, accomplish anything that allowing at-signs in
identifiers doesn't.
Well, there's some sort of abbreviation rule, but all that
does is to mess things up horribly. It is now possible for
two *different* names to refer to the *same* module. It is
also possible for a module (with no mentions of its name
anywhere other than ?MODULE) to break if you change its name.
In fact, changing the name of a module that doesn't mention
its name ANYWHERE other than the -module directive can break it.
Why I say it's inside-out is that "compound names" for modules
need to be relative to the starting module, not "absolute",
so that you can move an entire cluster of related modules
in a single renaming, WITHOUT having to hack on every single
file.
The design also perpetuates a great nastiness from Java, that
of mixing up the dotting structure of module names with the
arrangement of files in a file system. I have just spent a
painful half hour trying to read the documentation and sources
for a Haskell package I'd like to use. They've followed Java's
lead with module names. One result is that what seems to this
potential user like *ONE* thing is actually broken up into
about 30 pieces; instead of one coherent manual there are
disconnected bits all over the place. Instead of one directory
with all the source files, there is a great tree with files,
even files that are conceptually at the same level, not only
in different directories but in directories at different levels.
The right thing to do is to have a "configuration" language like
C/Mesa or LACE.
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions
« Return to Thread: Time to update programming rules?
| Free embeddable forum powered by Nabble | Forum Help |
