[Gambas-user] Static as a variable definition makes trouble

[Rolf-Werner Eilert]

Am 02.12.21 um 12:46 schrieb bb:
> On Thu, 2021-12-02 at 11:43 +0100, Tobias Boege via User wrote:
>> On Thu, 02 Dec 2021, Rolf-Werner Eilert wrote:
>>> I tried this
>>>
>>> Public Sub Timer1_Timer()
>>>    Static zlr As Integer
>>>
>>> but it says "Unexpected: Static"
>>>
>>> Why's this? Shouldn't this make a static variable "zlr" the value
>>> of which
>>> is kept from time to time?
>>>
>>
>> Documentation says that this feature will be available in Gambas
>> 3.17,
>> which has not been released yet. Are you sure that you are using the
>> development version of Gambas?
>>
>> Best,
>> Tobias
>>
> What an absolutely horrifying concept.  I struggled for some weeks as
> to why people wanted a static variable inside a function, but a static
> inside a public sub beggars belief. At least a function with static
> contents (read "there are better ways") has some credibility because if
> used properly is essentially just throw away memory that just remembers
> that it has been used before.
> But a dynamic method that declares a static variable? What happens when
> you have 45 timers all declaring some temporal value for a static? The
> mind literally boggles.
> I think there may be some misunderstanding as to what a static variable
> actually is??
> 
> To put it bluntly, it's a bit of memory that is in the class data space
> not the instance heap and if its not then there is something really
> wrong.
> 
> In fact, the more I think about it the less I believe in static
> variables inside functions as well. The idea of "saving" function
> internal values at the class dataspace by "making it static" appears to
> me to be reasonably risky. A specious argument, I know, but the idea is
> "just too hard".
> 
> If it is really truly static, then declare it in the class
> declarations. If not then you have got something wrong. MyTimer36.Delay
> should not return the class "MyTimer".Delay nor should setting it
> affect the other 44 timers. MyControl.X (or Y) declared as a static
> variable would mean everything is on top of each other. If the problem
> is really retaining values between calls, then there are ways to do it
> without having to resort to so-called "local statics".
> 
> Enough.
> b
>   

Hm. I made a class static one when I read that it's not possible yet. So 
I solved it exactly the way you describe.

I do see your point, but from the point of pure coding practice it is 
simply a counter which is only needed within the context of this Sub - 
so why should it be visible and useable to the whole class? To me this 
only bears the danger that I could mess it up if I used it in another 
function too. So I thought, better "capsule" it into this function.

Regards
Rolf