[erlang-questions] Why we need a -module() attribute?
Joe Armstrong
erlang@REDACTED
Thu Feb 25 10:05:54 CET 2016
On Thu, Feb 25, 2016 at 1:14 AM, Richard A. O'Keefe <ok@REDACTED> wrote:
> On 24/02/16 8:27 pm, Bengt Kleberg wrote:
>
>> Greetings,
>>
>> Would it be possible to get a more elaborate explanation of what OASES
>> would do?
>
> Map module names, grammar names, include names, &c to data sources,
> so that Erlang programmers would mostly deal with portable Erlang-internal
> names.
>>
>> Given the {module, my_app_part_subpart, "src/myapp/part/subpart.erl"}
>> example below, would src/myapp/part/subpart.erl be available as the module
>> my_app_part_subpart after being loaded in the VM?
>
> Yes.
>
>> How would src/myapp/part/helper.erl refer to it: my_app_part_subpart or
>> subpart or ???
>
>
> By the name that you provided in the -module directive.
> This is not a "hierarchical module names" proposal;
> the OASES idea is just "referring to resources in a portable way".
>>
>> How would src/myapp/other/subpart.erl refer to it: my_app_part_subpart or
>> part_subpart or ???
>
>
> By the name that you provided in the -module directive.
>>
>> I do not understand the "zip" thing enough to ask about it.
>
>
> This goes back to IBM mainframes, to Unix Makefiles, and to .ez files.
>
> In the MVS world, you might keep the Fortran code for your project
> in a "partitioned data set" (think Unix .a file) called FORTRAN, so
> you would refer to FORTRAN(DGEMM) -- the "DGEMM" member
> of the "FORTRAN" partitioned data set rather than a Unixy
> dgemm.f. Unix makefiles let you refer to files in a .a file using
> foobar.a(membername) and would automatically extract things.
>
> The idea is that you might want to package up a bunch of stuff in a
> ZIP file (or some other kind of archive), to save space, or to make
> it easier to move stuff around, or whatever. Why should you have
> to extract a file from an archive in order to read it? Why should
> the compiler not be able to read *directly* from the archive?
Yes - precisely - I *hate* systems that create thousands of small files
all over the place, why can't they tidy up their mess and stick them all
in a single zip file (or whatever). The widely used convention of
sticking everything in a zip file and then changing the extension to something
else seems like a good idea since the majority of users will think this is
a single files whose contents are unknowable (and thus cannot accidently
break the system by removing files) - whereas the odd programmer among us
who realise this really is a zip file can mess around with the contents.
This is the basic idea of abstraction - hide everything that you don't need to
know about in a single container.
it's also easier to delete things - I'm fed up with applications that
once installed
scatter files all over the file system and have no uninstall method.
Also easier to move things - if there's only one file to move things
are a lot easier.
/Joe
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list