Super-Static Variables Topic is solved

[DBN]

Super-global variables [v1.1.05+]: If a global declaration appears outside of any function, it takes effect for all functions by default. This avoids the need to redeclare the variable in each function.

It would be nice to allow the "static" keyword to be used in the same manner, initializing a global variable before the script starts so it can be referenced by other static initializers.

Support for combining the two effects in one variable (static global) would be a nice touch.

[Masonjar13]

Can you give an example as to when this would be needed?

[DBN]

Code: Select all

global static ConColor := { FG: __consoleMakeColors(0x0001, 0x0002, 0x0004, 0x0008), BG: __consoleMakeColors(0x0010, 0x0020, 0x0040, 0x0080) }

...
 
Log(type, msg)
{
	static colors := [ConColor.FG.Preset.DarkGray
	                , ConColor.FG.Preset.Gray
	                , ConColor.FG.Preset.Yellow
	                , ConColor.FG.Preset.Red  ]
	color := colors[type]
	if color =
		throw "Invalid message type: " type

	...
}

[Masonjar13]

The design you have there would be much better written into a class.

Code: Select all

class consoleLog{
    static ConColor := { FG: __consoleMakeColors(0x0001, 0x0002, 0x0004, 0x0008), BG: __consoleMakeColors(0x0010, 0x0020, 0x0040, 0x0080) }
    
    Log(type, msg){
        static colors := [ConColor.FG.Preset.DarkGray
                        , ConColor.FG.Preset.Gray
                        , ConColor.FG.Preset.Yellow
                        , ConColor.FG.Preset.Red  ]
        color := colors[type]
        if color =
            throw "Invalid message type: " type
     
        ...
    }
}

obj:=new consoleLog
obj.Log(type, msg)

My syntax may be off there, haven't used OOP in a year or two.

[DBN]

No, Log is something built on top of the console library and is in a different file altogether. And it's not possible to allocate more than one console per process.

[Masonjar13]

My statement stands. What you're asking for is OOP functionality in a procedural way. As of now, I don't see a decent reason why it should be supported. However, this is an open discussion; by all means, continue your proposition. I'm simply questioning the importance or potential gain of adding such a feature.

[DBN]

What I asked for was "initializing a global variable before the script starts so it can be referenced by other static initializers". You asked for an example and I provided one. Please no more strawman.

[Masonjar13]

There's no need to be crude. I adequately challenged your proposition and stated your example was a poor one, as nicely as I could without being blatant.

I'm simply questioning the importance or potential gain of adding such a feature.

You haven't stated the usefulness of adding such a feature.

[DBN]

I explained that the code does not belong in a class and you replied with "My statement stands." without explaining why.

Normal code has access to global variables and this has well recognized utility.
Static code does not have access to global variables. If it did, it would have the same utility as normal code accessing normal globals.

You appear to be arguing that any code needing such access should be restructured into one big singleton class. This is contrary to the good practice of breaking up code into smaller independent parts.

[nnnik]

I really don't know if that fully fulfills the effect you wanted but you can use functions for something similar:

Code: Select all

functionA(params)
{
static colors := initColors()

}
InitColors()
{
	return {black:0,white:0xffffffff}
}

[DBN]

Slightly better would be:

Code: Select all

ConColors()
{
	static o := {black:0,white:0xffffffff}
	return o
}
functionA(params)
{
	static color := ConColors().black

}

Or, the way I'm working around it at the moment:

Code: Select all

global ConColors
__ConColors()
{
	static dummy := ("", ConColors := {black:0,white:0xffffffff})
}
functionA(params)
{
	static color := ConColors.black

}

[nnnik]

I think you are also going to like:

Code: Select all

class Colors
{
	static black := 0x0,white := 0xFFFFFFFF
}

function()
{
	static black := Colors.black , white := Colors.white
	Msgbox % black . "`n" . white
}

function()

[lexikos]

Related: Static init functions (was: Goto Eof) (and probably other topics; it's not a new idea).

Consider this: why was the word "static" chosen for static variables in functions - what meaning does it have?

[lexikos]

I think the issue this was intended to solve is that static initializers in v1 are implicitly "hoisted" to the top of the script, so any initialization performed at the actual top of the script will be too late. At some point I concluded that adding another way to "hoist" an auto-executed code fragment would fail to adequately solve the inherent problems. Even with additional complicated ways to specify the order in which to execute each code fragment, there are likely to be issues with order of evaluation.

v2 mitigates such issues by evaluating static initializers when they are encountered for the first time during execution of the function (and initializing classes when they are first referenced). Scripts can be structured such that global code is used only for initialization, with the main program being executed at the end (e.g. by calling Main(A_Args)). This allows global variables associated with functions or hotkeys to be initialized near where the hotkey or function is defined.

v1 will remain as is.