[erlang-questions] -pidname( <atom> ) Was: Why we need a -module() attribute?

[ok@REDACTED]

>> Almost all process registrations should be local to the module that
>> registers
>> them.  I proposed
>>
>>      -pidname(<atom>).
>>
>> for declaring a module-local atomic variable to hold pids.  This would
>> be both
>> safer than the global registry and more efficient.  The global registry
>> would
>> remain for those things that genuinely need to be global.
>
> Presuming that the module name is , say,  test,  how is:
>
> -pidname( test )
>
> different from:
>
> register( ?MODULE, self() )?

First off, let me repeat that a pidname directive declares
a MODULE-LOCAL (as in COMPLETELY INACCESSIBLE FROM THE OUTSIDE)
atomic variable.

Second, a module name names a module, a pidname atom names a
pid variable.  They are not the same thing and there is no
compelling reason for them to have the same name.  Indeed, a
module may declare as many pidnames as it needs; they cannot
all have the same name as the module.

Third, -pidname just *declares* a module-local variable for
holding pids, it doesn't register anything.  You'd have to
do something like pidname:set(<the atom you declared>, self()).

Fourth, just in case you missed it, the whole point is that
a pidname is strictly LOCAL to its module.  It cannot even be
seen from the outside.  It's private.  Using the registry,
every process in the whole node can not only *see* your binding,
they can *delete* it or *replace* it.  With -pidname, no can do.
You're safe, and there's no risk of you accidentally clobbering
someone else's registry entry either.

>
> Also, how would you run multiple instances of the same module within the
> same run-time?

Why would that even come close to the shadow of the hint of a
problem?  Each instance has its OWN variable.  That's what
module-local means.

So if you have a module that hides a process, you can load a new
version and start it, and calls still executing in the old copy
will still be routed to the old process; the registry entry won't
(can't) be hijacked by the new module instance.

> Your proposal may appear to solve one problem (that is, if one chose to
> call it a problem), but appears to introduce at least one more.

It may well do so, but you have not identified any.

It's an anachronism, because nobody had ever heard of Java
when I invented -pidname, but think of
    -pidname(fred).
as an analogue of
    private static Thread fred = null;