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