<div dir="ltr">Wasn't quite clear. I'm assuming that there are three constructors for a singleton and that they are incompatible - otherwise why not have one method?<div>If I'm wrong about them being incompatible, then have only a single method and move the variance to another method.</div><div><br><div>I suggested exception because if one has already been created, and you ask for a now incompatible one, it should be an error. Calling the successful getSingleton again should succeed. </div></div><div><br></div><div>I'm assuming the getSingleton method(s) are synchronized on the same object (the Class in this case).</div><div><br></div><div>The advantage over the old way is that there isn't a race condition.</div><div><br></div><div>Actually, I'm not sure why only one interpreter is allowed. An alternative would be to have separate createInterpreter, getDefaultInterpreter or better, just use new to get a private interpreter instead of having a createInterpreter.</div><div> </div><div>createInterpreter/new always succeeds and returns a non-global interpreter you need to keep track of yourself. getDefaultInterpreter either returns the static interpreter or creates, stores, and returns it.</div><div><br></div><div>Having a createXXX that returns nil and sometimes returns an interpreter makes no sense to me.</div><div><br></div><div>If we land up refactoring, I'd also propose we move the j stuff to a separate class.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 13, 2019 at 4:15 AM Mark Evenson <<a href="mailto:evenson@panix.com">evenson@panix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Mar 12, 2019, at 21:10, Alan Ruttenberg <<a href="mailto:alanruttenberg@gmail.com" target="_blank">alanruttenberg@gmail.com</a>> wrote:<br>
> <br>
> Ok,<br>
> 3 getSingleton methods, one for each case, synchronized.<br>
> First one wins. Subsequent ones throw an exception, since you can't have more than one.<br>
<br>
This doesn’t smell good to me.<br>
<br>
One should be able to have multiple references to a singleton, as long as there<br>
is only one singleton.  Consider the use of ABCL in a Java Servlet context<br>
where each instance of the servlet is processing a separate, parallel request.<br>
Each such Servlet begins its lifecycle by getting a reference to the singleton<br>
ABCL instance, and then calling into ABCL to service the request.<br>
<br>
Maybe you meant “three create singleton methods, synchronized”?  This is<br>
similar to what we have now, using an exception rather than returning a null on<br>
failure.  This would be a breaking change for existing users of the interface,<br>
as they would have to change their code to deal with the exception (unless we<br>
throw something that inherits from RuntimeException which would be even worse).<br>
Philosophically, Java exceptions should not be used for anticipated failures,<br>
as they are not potentially restartable like Common Lisp conditions.<br>
<br>
<br>
-- <br>
"A screaming comes across the sky.  It has happened before but there is nothing <br>
to compare to it now."<br>
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div>