[v2.0-beta.1] The value of the class variable may not be available in __delete when the program is ready to finish

[thqby]

@lexikos
When the program ends, in the `__delete` meta-function, the class variable is released without getting a value, whereas the function does.

Code: Select all

class abc {
    __Delete() {
        MsgBox(Type(abcd))  ; Func
        MsgBox(Type(abc))   ; String
    }
}

abcd() {

}

b := abc()

The difference is that ResultType Script::PreparseVarRefs(), when it's a function, !token->var->IsUninitialized() equal to true, the line token->var->ToToken(*token); will be executed; when it's a class, !token->var->IsUninitialized() equal to false, var will not be converted to object.

[swagfag]

seems like more of the same viewtopic.php?p=322846#p322846

When the script exits, objects contained by global and static variables are released automatically in an arbitrary, implementation-defined order. When __Delete is called during this process, some global or static variables may have already been released, but any references contained by the object itself are still valid. It is therefore best for __Delete to be entirely self-contained, and not rely on any global or static variables.

not exactly a bug per se

[lexikos]

swagfag is correct.

The "uninitialized" flag is used to force class initialization when the script accesses the class variable for the first time. After that (and always before __delete is called), the class variable loses the "uninitialized" flag.

The names "abc" and "abcd" are resolved to "variables" at load time. The function reference may be further resolved from a variable reference (SYM_VAR) to an object reference (SYM_OBJECT) at load time, for efficiency (although in practice I think it makes negligible difference; and it might not occur for nested functions). Since the expression has a direct reference to the object, when the variable "abcd" is released during script termination, it has no effect on type(abcd). This is a side-effect of the implementation and not guaranteed.

By contrast, the class "abc" cannot be resolved from SYM_VAR to SYM_OBJECT at load time, because it would interfere with the initialization mechanism.

[thqby]

Maybe you are right.
In my simple tests, I found that class resolving from SYM_VAR to SYM_OBJECT at load time also works fine, so I have this doubt.

[lexikos]

No, classes are not resolved from SYM_VAR to SYM_OBJECT at load time in the current version. Whatever you found, it is not that.

[thqby]

I modified and tested it based on the current version.

[lexikos]

Your last two posts are very vague.

If you changed class variable references to be resolved to SYM_OBJECT at load time, you broke static class initialization.

Code: Select all

MsgBox X.Y ; 1
class X {
    static Y := 1
}