[M3devel] proposal for dealing with lazy console--please review and comment!

Olaf Wagner wagner at elegosoft.com
Thu Jun 19 08:55:10 CEST 2008


Quoting Jay <jayk123 at hotmail.com>:

> Randy, just because the initialization happens early does not mean   
> you can't affect the behavior later. The type can be changed at   
> initialization time, and then the instance configured later. Unless   
> you are worried about other module initializers ignorantly calling   
> stdout.Wr() and causing the console to appear? If so, yeah.
>
> How about @M3 command line parameters instead?
> At least they aren't "sticky" and can be more easily localized to a   
> single process.
What does sticky mean here?

> I ignore sh's feature here usually, and in this case that makes good sense.
environment variables aren't a feature of shells, but or process
contexts. Shells just allow to set them explicitly.

> "Command line parameters are better than environment variables".
> Supporting both is reasonable.
Yes, if we go this way, we should support both options.
An environment variable overrides a built-in default, and an
explicit parameter overrides the environment setting if present.

> However, if so, and if it is an @M3 variable, there should perhaps   
> be one variable to contain @M3 options??
Something like `@m3opt=lazyconsole,dontcrash,whatsoever'?
What other options do you have in mind?

> Still I'm not a fan of globals like this. I think it should be   
> configurable per type instantiation.

> You could also imagine that one variable is the "during   
> initialization time" configuration, and then once Main starts,   
> another configuration takes over, since by then whoever wants to set  
>  it has had a chance to run.
>
> Btw, sleazy, but you could also make it a built-time configuration.   
> You could easily build your m3core.dll to have one default behavior,  
>  while everyone else's has another.

I think we'll have to decide which way to go, as Randy needs a
solution to continue his work. Currently the easiest approach
seems to be the environment variable/command line solution indeed,
as no interface need to be touched and no new modules are required.

Would anybody object to this approach? More control could easily be
added later, if that is really required. (After all, this currently
is just a problem for Windows GUI programs.)

What about M3_LAZY_CONSOLE and @M3lazyconsole for a start?

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194




More information about the M3devel mailing list