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.
On Tue, Mar 12, 2019 at 2:28 PM Mark Evenson evenson@panix.com wrote:
On Mar 11, 2019, at 21:47, Alan Ruttenberg alanruttenberg@gmail.com
wrote:
I haven't looked at this code before, but in looking now, I am confused. Interpreter is intended to be a singleton, right? (that's what the
comment says, as well as what is suggested by the use of the static interpreter variable.).
In that case why would you want to createInstance to ever return null? Why isn't there just a single synchronized getSingleton() (call it
getInterpreter if you want) method, which either returns returns the existing interpreter, or creates and initializes a new one and returns it.
My current take on the code is that createInstance() returns null due to there being three different code paths for initialization, so the “getInstance() calls create” can’t be wrapped in a single method.
The three different kinds of creation of the interpreter are:
- createInstance() for “embedded" uses
- createDefaultInstance() for bringing up the REPL
- createJlispInstance() for use in the J editor
Each initialization path populates the static reference for the Interpreter singleton, and then proceeds to mutate the necessary state for its purposes. As such, the mere existence of the interpreter reference does not mean that all the necessary mutation has completed. In lieu of a proper semantic for having finished creation, each code path starts by checking to see if there is a value for interpreter, punting with a null value if this is not the case with the following stanza:
if (interpreter != null) return null;This is all very suboptimal from a user perspective, as getting a null from a call to create expecting the caller to handle the error is just wrong.
Still thinking about how to simplify this…
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."