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

[Richard A. O'Keefe]

On 27/02/16 3:53 am, Valentin Micic wrote:
Far from being an oxymoron, ensuring atomicity is surprisingly tricky.

>
> And when you say COMPLETELY INACCESSIBLE FROM THE OUTSIDE, I assume 
> this would exclude read access as well.

Yes.
> If the whole point of registering processes is to be able to provide 
> for a static way of sending a message to a process, how would that 
> work under these circumstances?
I'm not sure what you mean when you refer to 'a static way'.
The existing registry is *dynamic*, and so are pidnames.

There are presently many modules, and books and training materials recommend
creating more, where a module creates a process which *that* module needs to
communicate with but which *no* other module should be able to contact 
directly.
That's the problem -pidnames solve.
>
> Are you saying that one can have more than one -pidname declaration 
> per module?

Yes.
>
> Don't you think this would mean that you would have to know in advance 
> (that is, compile-time) about all the names the process powered by 
> this module would ever have?

Yes.  (Except that you could support an unbounded number of names by
creating a private registry *process* and binding that to a pidname.)
> If so, I am quite surprised that you do not see a problem with that.
I don't see a problem with that because there is an abundance of modules
where there *is* a design-time-known set of processes to refer to. As far
as I can tell, this is in fact the *usual* case.

The -pidname proposal is NOT a replacement for the existing registry,
but a much safer alternative for the many modules that need *private*
names.  If that's not your use-case, just keep on using the existing
registry.
>
> Also, seeing that module name and named pidname variable are not the 
> same, what would happen if two different modules uses the same 
> name for a pidname?

Nothing,  The whole *point* of -pidnames is to be *private* to their 
containing
module.
> Of course, you may solve this problem by indicating that these are 
> COMPLETELY INACCESSIBLE FROM THE OUTSIDE, but again, assuming that the 
> reason for registration is to be able to have a "static" way to send a 
> message to a process, what would be the point of having them in the 
> first place if they are COMPLETELY INACCESSIBLE FROM THE OUTSIDE.

Because you don't WANT them to be accessible from the outside.
Because in fact you are terrified that somebody might access them
from the outside, causing horrible breakage.  A very common pattern
is that a module contains two kinds of code:
   - code to be executed by a process
   - code for the protocols used to communicate with that process
In order to find the process, the protocol code needs to find it.
Currently, people use the registry, but that makes the module
vulnerable to
   * accidental or malicious deletion of the registry entry
   * accidental or malicious replacement of the registry entry
   * accidental or malicious sending of messages to the process
      without the mediation of the protocol code.
In order to prevent that, you need something like a registry entry
that is private to the module.  "The point of having them in the
first place" is *precisely* to be "completely inaccessible from the
outside".  There is no other reason for having them.
>
> Given the Erlang standard syntax, it stands to reason that 
> pidname:set( <the atom you declared>, self() ) invokes a function set, 
> that belongs to another module (pidname), and, as such, goes against 
> your earlier stipulation that -pidname declarations are  COMPLETELY 
> INACCESSIBLE FROM THE OUTSIDE.

False.  I used function call syntax (a) as a quick expedient in exposition
and (b) because there isn't really anything else to use.  The intention is
that they would really be special syntax that just happens to look like a
function call.
>
> See a contradiction that I attempted to point out above...
I could find no contradiction.

> When I say instance, well, I actually mean a process, as this is what 
> we register today (and we do that so we can use a symbolic reference 
> instead of pid() in order to send messages to it).
> In ideal situation, you would have 1:1 correspondence between a module 
> and a process.
I don't see why.  I can't think of any concurrent programming language 
I've ever used
that has had such a correspondence, or any text on concurrent 
programming that has
recommended such a correspondence.  I certainly have modules that exist 
to let a
caller create concurrent data structures, as many as they want, and I 
don't understand
why that would be disparaged.

> However, this is rarely the case; e.g. what we register as a 
> gen_server is not the gen_server module, but the actual behavior that 
> runs on top of gen_server. So, which -pidname variable should we use?

Where did you get the idea that -pidnames are meant to do *everything*?

> And let me just reiterate a point that I've made commenting on your 
> Second point above -- are we to provide gen_server with as many names 
> as we have behaviors?

I repeat, where did you get the idea that -pidnames are meant to do 
*everything*?

Pidnames are for use when you need *private* names for a *known* set of
processes.  If that's not your use-case, use something else.
> The point is, you cannot possibly predict all deployments any given 
> module may have.

Of course.  And I don't *care*.  All that matters is whether the designer
of a module knows about a set of processes s/he wants to *hide*.

(Another version of this may have appeared.  ThunderBird seemed to have
completely lost it.)