| Author |
Message |
< Erlang ~ Module names mandatory? |
| ultranewb |
Posted: Mon Jan 10, 2011 5:04 pm |
|
|
|
User
Joined: 10 Jan 2011
Posts: 10
|
Was semi-interested in learning Erlang, so started reading a tutorial.
At any rate, in the tutorial something jumped out at me right away - the (apparent) need to use a module name after defining a function. Example, you've written a function called "blah" in a module called "whatever," it appears that you would call the function by writing:
whatever:blah().
Is this correct? If so... (this may sound like a crazy question)... is there any way to avoid it or get around it? If not a "normal" way, then perhaps a "macro" or a "#define"?
Thanks. |
|
|
| Back to top |
|
| jwarlander |
Posted: Tue Jan 11, 2011 6:06 pm |
|
|
|
Joined: 11 Jan 2011
Posts: 1
|
You can import selected functions from another module, so you don't have to type the module name:
foo.erl
Code: -module(foo).
-export([main/0]).
-import(bar, [hello_world/0]).
main() ->
hello_world().
bar.erl
Code: -module(bar).
-export([hello_world/0]).
hello_world() ->
io:format("Hello, World! (from bar)~n").
|
|
|
| Back to top |
|
| ultranewb |
Posted: Wed Jan 12, 2011 2:07 am |
|
|
|
User
Joined: 10 Jan 2011
Posts: 10
|
Ahh, that's what I needed to know. Thanks.
What about macros? Would they work? |
|
|
| Back to top |
|
| zajda |
Posted: Wed Jan 12, 2011 3:22 pm |
|
|
|
User
Joined: 22 Aug 2009
Posts: 83
|
hmm import is possible, but I think it is kind of antipattern and it makes mess in the code.
Regarding function calls, its a bit complicated.
Code exists in ErlangVM in two version. Both versions are valid and can be executed at one time.
Fully qualified call (module:function(Arg)) always use the newest code available in VM.
btw. you do not have to use fully qualified call to local functions, right? |
|
|
| Back to top |
|
| rvirding |
Posted: Mon Jan 24, 2011 10:56 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
When you call a function in the same module there is no need to give the module name. However, when calling a function in another module qualifying the function name with the module name, module:func(...), is mandatory.
Calling functions interacts with code handling. There are at most two versions of code for a module, the current or new and the old versions. Calling a function in another module, with the qualifying module name, always calls the new code version. Calling a function in the same module will call the same code version as the calling function. Qualifying a call to a function in the same module with the module name will, however, call that function in the new code version. So qualifying with the module name always give you the new code version.
Only functions which have been exported from a module can be called from another module or from the same module if the call has been qualified with the module name.
Using -import(...) changes nothing here. It is pure syntactic sugar and behaves exactly the same as if the module name had been explicitly used. Many don't like using import saying that it makes it harder to understand the code. Personally I only use for some common much used library modules like lists. |
_________________ Robert Virding, Erlang Solutions Ltd. |
|
| Back to top |
|
| ultranewb |
Posted: Tue Jan 25, 2011 1:47 am |
|
|
|
User
Joined: 10 Jan 2011
Posts: 10
|
<<Many don't like using import saying that it makes it harder to understand the code.>>
I am strongly of the opposite mentality. I hate syntactic crap mucking up my code and getting in the way of the actual logic of the program. It is why you couldn't pay me to code in Java, with reams of static.void.main.yadda.blah.blah. Thank God this language has a way for me to minimize that stuff, otherwise I wouldn't fool with it. I'm using a combination of export_all, import, plus macros. |
|
|
| Back to top |
|
| rvirding |
Posted: Wed Jan 26, 2011 1:31 pm |
|
|
|
User
Joined: 30 Aug 2006
Posts: 452
Location: Stockholm, Sweden
|
| I only use export_all when writing or debugging a module. You should only export those functions which are part of the API, exporting internal functions usually leads to woe. |
_________________ Robert Virding, Erlang Solutions Ltd. |
|
| Back to top |
|
|
|