[erlang-questions] Re: Will parameterized modules become an official part of Erlang?
Mon Feb 22 08:53:57 CET 2010
I have no opinion on any of these (extends, packages, parameterized
modules) at the moment. I'm wondering, however: perhaps it would be
wise if, in the future, these sorts of experimental extensions were
announced and supplied *only* if they came with refactoring tools for
reverting the code, so that people who committed strongly to the use of
such a feature could always back out later, if the idea dead-ends?
I looked briefly at parameterized modules, but I got cold feet when I
noticed they weren't officially supported. If there were some way to
use them with the confidence that, if dropped, one could automatically
transform code that uses them into something that doesn't use them,
with little loss of legibility and no new errors introduced, I probably
would have been more inclined to experiment. And you want a lot of
experimenters, to inform and support any keep/drop decision.
On 2/22/2010, "Andrew Thompson" <> wrote:
>Personally I'd list them in this order (of increasing dislike):
>* -extends - this one doesn't really affect you unless you're using it
> yourself - the end user doesn't have to care (although writing a
> behaviour is probably just as good).
>* packages - these can affect you if you're using a library that someone
> decided to use packages in but you can probably think of them as just
> modules with dots in the name.
>* parameterized modules - these are the ones that really screw with the
> end user. I had a real headache when I first tried to use them in
>Basicially since I wouldn't use any of them in any of my projects I
>mainly look at them from the point of view of the inconvienience when I
>try to use someone else's code that uses them.
>erlang-questions (at) erlang.org mailing list.
>To unsubscribe; mailto:
More information about the erlang-questions