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?
If I'm wrong about them being incompatible, then have only a single method and move the variance to another method.

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. 

I'm assuming the getSingleton method(s) are synchronized on the same object (the Class in this case).

The advantage over the old way is that there isn't a race condition.

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.
 
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.

Having a createXXX that returns nil and sometimes returns an interpreter makes no sense to me.

If we land up refactoring, I'd also propose we move the j stuff to a separate class.

On Wed, Mar 13, 2019 at 4:15 AM Mark Evenson <evenson@panix.com> wrote:


> On Mar 12, 2019, at 21:10, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>
> Ok,
> 3 getSingleton methods, one for each case, synchronized.
> First one wins. Subsequent ones throw an exception, since you can't have more than one.

This doesn’t smell good to me.

One should be able to have multiple references to a singleton, as long as there
is only one singleton.  Consider the use of ABCL in a Java Servlet context
where each instance of the servlet is processing a separate, parallel request.
Each such Servlet begins its lifecycle by getting a reference to the singleton
ABCL instance, and then calling into ABCL to service the request.

Maybe you meant “three create singleton methods, synchronized”?  This is
similar to what we have now, using an exception rather than returning a null on
failure.  This would be a breaking change for existing users of the interface,
as they would have to change their code to deal with the exception (unless we
throw something that inherits from RuntimeException which would be even worse).
Philosophically, Java exceptions should not be used for anticipated failures,
as they are not potentially restartable like Common Lisp conditions.


--
"A screaming comes across the sky.  It has happened before but there is nothing
to compare to it now."