Hi Marcel,

On Wed, Dec 09, 2020 at 11:21:15AM +0100, Marcel Taeumel wrote:
> Hi David.
> 
> Thanks for working on this! :-)
> 
> That special case in "Delay" reminds me of the suggestion to just put "DoItFirst" at a more sensible place in the start-up list. But then it would not be "do it first" anymore. :-D Same for FileDirectory.
>

Pretty much everything I tried needed a bit of hackery someplace,
and in the end it seemed simplest to do everything from the first
position in the startup list, with whatever minimal hacks were needed
to make this work.

I found that the only command option that could not be processed from
the first entry in the startup list was --debug. It works when run after
the Delay startup, but not before. So I arranged for the command "action"
to be registered in the DoItFirst startup, but not actually invoked until
the end of the Delay startup.

The FileDirectory hack is not strictly required, but without it the --cwd
setting gets reset to the normal default later in the startup processing.
Thus it would be active for e.g. any --doit options, but would be reset
by the time the image finishes startup processing. Arguably that behavior
might be considered more correct, but it would be confusing to someone
who specified a --cwd option and expected it to take effect for the
image overall. The "solution" was to add a second invocation of the
--cwd option at the end of the FileDirectory startup.
 
> What about a little bit more "double dispatch"?
> 
> (Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit startUpFromDelay ].
> 
> (Smalltalk classNamed: #DoItFirst) ifNotNil: [ :doit | doit startUpFromFileDirectory ].
> 

The tricky part is still there - how do you arrange for the option
blocks to be evaluated at the earliest possible time, but no sooner?

Dave