I recently found out that I should not be using parameterized modules in Erlang (the new keyword) as they are experimental and may be removed. What other things should I not be using, and why?
views:
177answers:
1
+9
A:
- Parametrised modules
- Extends (I can't work out if this is a part of the parametrised modules or not)
- Packages
These are in the order of my increasing dislike, so I would accept parametrised modules without too much grumbling but would actively fight against packages.
One thing to keep an eye on is NIFs, native implemented functions. They are still experimental but I am certain that they will become standardised in a not too future release. Used in the right way they can be very useful.
rvirding
2010-02-18 21:10:15
I'd never even heard of packages before. What are they?
Zubair
2010-02-18 21:22:38
Packages are namespaced modules. Nobody uses them and there are long discussions on the mailing lists on why they are a bad idea. It's one of those features no-one knows why exists really.http://www.erlang.se/publications/packages.html
Jon Gretar
2010-02-18 22:52:15
As far as I know, extends are not part of parametrized modules, but people who want to program OO in Erlang always try to couple both features together.
I GIVE TERRIBLE ADVICE
2010-02-18 23:01:18
Hear, hear. I'd put Parametrised modules at the top of my list because they get the most (ab)use and because packages are sufficiently broken to discourage any use at all. :)
archaelus
2010-02-19 05:02:36
Added bit about NIFs.
rvirding
2010-02-19 15:20:05
One use for extends is to create "Adapters" for behaviors. E.g. my gen_servers usually implement only two or three functions of the gen_server behavior. The rest can simply be inherited (extended) from a gen_server_adapter module.
Zed
2010-02-19 15:31:07
If gen-servers use "extends" then does this mean that OTP uses experimental Erlang?
Zubair
2010-02-20 08:43:47
Do you mean that gen_server.erl uses extends, or that OTP gen_servers use extends, or that user code **using** gen_server uses extends? I have greped the R13B03 code and extends is only mentioned when it is implemented, it is never used. So I would say **no** OTP does not use experimental extends, and if user code does that does not mean that OTP does.
rvirding
2010-02-20 19:46:51
What I understand is that he defines a basic gen_server callback module with all the default functions implemented (probably ignoring the calls and just returning default values). After that, every gen_server callback module Zed writes extends that basic callback module. His new implementation thus no longer needs the boilerplate handle_* functions he might not be using as the VM will automatically go look in the extended module for these.
I GIVE TERRIBLE ADVICE
2010-02-20 21:02:32
I meant that most of the time when I implement a gen_server, I only use two or three callbacks (init, handle_call, handle_cast). Yet, because gen_server behavior has six callbacks, I must implement sic callbacks, having useless code chunks in my source like `handle_cast(_Cast, State) -> 'noreply', State}.`. As a solution I create a my_gen_server_adapter module, having a default implementation for all six callback functions. I extend my gen_server implementations from this, and only redifine the callbacks I actually use.
Zed
2010-02-21 15:37:48
Ah, but that will not stop the warnings from the compiler. I see what you are doing but I am still not convinced that it should be added. A trouble with all these "features" is that they tend to interact with one another.
rvirding
2010-02-22 11:44:35