<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On 26 Feb 2016, at 1:52 PM, <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> <<a href="mailto:ok@cs.otago.ac.nz">ok@cs.otago.ac.nz</a>> wrote:</div><div><div><div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite">Almost all process registrations should be local to the module that<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">registers<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">them. I proposed<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"> -pidname(<atom>).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for declaring a module-local atomic variable to hold pids. This would<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">be both<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">safer than the global registry and more efficient. The global registry<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">would<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">remain for those things that genuinely need to be global.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Presuming that the module name is , say, test, how is:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-pidname( test )<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">different from:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">register( ?MODULE, self() )?<br></blockquote><br>First off, let me repeat that a pidname directive declares<br>a MODULE-LOCAL (as in COMPLETELY INACCESSIBLE FROM THE OUTSIDE)<br>atomic variable.</div></blockquote><div><br></div><div>Phrase "atomic variable" in a context of Erlang is a bit counter-intuitive, maybe even to a point of being an oxymoron.</div><div><br></div><div>And when you say COMPLETELY INACCESSIBLE FROM THE OUTSIDE, I assume this would exclude read access as well.</div><div>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? </div><br><blockquote type="cite"><div><br>Second, a module name names a module, a pidname atom names a<br>pid variable. They are not the same thing and there is no<br>compelling reason for them to have the same name. Indeed, a<br>module may declare as many pidnames as it needs; they cannot<br>all have the same name as the module.<br></div></blockquote><div><br></div><div>Are you saying that one can have more than one -pidname declaration per module?</div><div><br></div><div>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?</div><div>If so, I am quite surprised that you do not see a problem with that.</div><div><br></div><div>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?</div><div>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.</div><div><br></div><blockquote type="cite"><div><br>Third, -pidname just *declares* a module-local variable for<br>holding pids, it doesn't register anything. You'd have to<br>do something like pidname:set(<the atom you declared>, self()).<br></div></blockquote><div><br></div><div>Given the Erlang standard syntax, it stands to reason that <font class="Apple-style-span" face="'Courier New'">pidname:set( <the atom you declared>, self() )</font> invokes a function <font class="Apple-style-span" face="'Courier New'">set</font>, that belongs to another module (<font class="Apple-style-span" face="'Courier New'">pidname</font>), and, as such, goes against your earlier stipulation that <font class="Apple-style-span" face="'Courier New'">-pidname</font> declarations are COMPLETELY INACCESSIBLE FROM THE OUTSIDE.</div><div>And, if they are accessible from the outside via <span class="Apple-style-span" style="font-family: 'Courier New'; ">pidname:set( <the atom you declared>, self() )</span>, how is that any safer than the registration mechanism already in place?</div><div><br></div><blockquote type="cite"><div><br>Fourth, just in case you missed it, the whole point is that<br>a pidname is strictly LOCAL to its module. It cannot even be<br>seen from the outside. It's private. Using the registry,<br>every process in the whole node can not only *see* your binding,<br>they can *delete* it or *replace* it. With -pidname, no can do.<br>You're safe, and there's no risk of you accidentally clobbering<br>someone else's registry entry either.<br></div></blockquote><div><br></div><div>See a contradiction that I attempted to point out above...</div><br><blockquote type="cite"><div><br><blockquote type="cite"><br></blockquote><blockquote type="cite">Also, how would you run multiple instances of the same module within the<br></blockquote><blockquote type="cite">same run-time?<br></blockquote><br>Why would that even come close to the shadow of the hint of a<br>problem? Each instance has its OWN variable. That's what<br>module-local means.<br></div></blockquote><div><br></div><div>I wish I can understand this as easily as you can.</div><div><br></div><div>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).</div><div>In ideal situation, you would have 1:1 correspondence between a module and a process. 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?</div><div>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? Of course not. However, if we have a module gen_server declaring a -pidname( gen_server ), and if we send a message to a gen_server, where would this message go?</div><div><br></div><div>The point is, you cannot possibly predict all deployments any given module may have.</div><br><blockquote type="cite"><div><br>So if you have a module that hides a process, you can load a new<br>version and start it, and calls still executing in the old copy<br>will still be routed to the old process; the registry entry won't<br>(can't) be hijacked by the new module instance.<br><br><blockquote type="cite">Your proposal may appear to solve one problem (that is, if one chose to<br></blockquote><blockquote type="cite">call it a problem), but appears to introduce at least one more.<br></blockquote><br>It may well do so, but you have not identified any.<br></div></blockquote><blockquote type="cite"><div><br>It's an anachronism, because nobody had ever heard of Java<br>when I invented -pidname, but think of<br> -pidname(fred).<br>as an analogue of<br> private static Thread fred = null;<br></div></blockquote><div><br></div><div>There are some problems outlined above. I am sure you would be able to think of more yourself. </div><div>But then again, I may have missed the point completely. It wouldn't be the first time.</div></div><div><br></div><div><br></div>Kind regards</div></div></div><div><br></div><div>V/</div><div><br></div></body></html>