once again: the private scope

[ReneMiner]

for a really working private scope as known from other language we would need to gather a lot of information where always some functionality is missing.
the sdk-function "thinBasic_StackGetList" seemed to be the clue and solution but - i fell for it and confused "stack level" and "scope" considering both to be something equal. but no...



Remind again: a scope means an area where variables are shared by the scopes members . properties that are excluded from sharing become somewhat personal
without the need to declare them being private.

Any class and udt already defines their basic scopes between type/class and end type/end class. Statics that we have currently are not really it since we can access the staics - whch is not bad- from almost anywhere if it were possible to make the current statics in udts to behave as equates that do not allow second assignments we had
kind of udt-related constants but no use for them in a private scope...

If Type extends another type logically the new type has its own scope but part of it were the common scope of the functions and properties the both have in common . But the scope before creating a type that extends it remains on the range of the extended udt. That would become pretty much complicated pretty soon

- so i thought what if we forget what other languages work like, define the scopes ourselves to our needs and maybe create artificial auto-appearing scopes somewhere inbetween the global level and the scriptfunction level.

a new class of variables that are neither local nor global. remain the current 2 scopes as they are just create an artificial scope for each udt so we can create variables of the new class within type-end-type additional to the current properties even outside of type-functions that are useable in all functions that begin with the same types-name in their function name.
not local - not global but

Regional

that is udts first and last lines build a region of their own without any keyword if the udt-definition is not enclosed by a region completely. Intersections or region definitions starting outside of type-end type can not have the other regions limitation somewhere inbetween,

#Region to #EndRegion as current remain as they are. additional new #Region and #Endregion will have a keywords inbetween #Region and the quoted string with the regions name that shall become the name of the scope. , the associated #EndRegion is followed by that new keyword



#Region Shared "MyScope"
' udts created enclosed completely within these borders will not have another region of their own.
' functions & subs must be all lines enclosed from function to end function inside the same shared region
' shared regions can not intersect nor embed other shared regions. shared is anything that is
' dimensioned within a shared region with the new keyword Regional.
#EndRegion Shared
'
' ...
'
- what is here remains global scope

' ...
'
Region Shared "exclavation" Extends "myScope"
' shared regions are not required to be continous in 1 section of the script. Multiple regions at different
' positons should be able join a regional scope. keyword Extends borrowed from the Types...
' all in here does not have a separate area where regional variables are valid ,
' all as Regional created variables from "exclavation"
' and myScope are in the same pool
#EndRegion Shared

#Region Shared "mySecretScope" Private
' private prevents fom getting extended and blocks this region both ways-
' the place where Extends had to go is covered. regions that would like to
' join and extends "mySecretScope" are not permitted.
#EndRegion Sharesd




now any functions that are enclosed inside such regions should know in what scope they exist, udt functions can be all members of the same scope when the udt completely is enclosed by a shared region. It were possible for different udt-functions to use extends so the members of the udt are not required to be all inside of
thhe same scope. Anyway udt-functions can be defined as subelements
elementname As Function
which allows to exclude some function from the shared region without anyway not permitted intersections between shared regions

regional scope require on functions only a property that lets these know the scope ???
or better probably shared regions know all the functions names that are within theirs limits. udts could ... build a region of their own if they dont have any functions outsourced nor functions that extends any shared regions - or none. Still the option to enclose an udt with Region Shared "whatever" Private

[ReneMiner]

I forgot something concerning the current udts.
It were a big step already if udt-functions had virtual layovers or invisible byref into functions passed variable-names to allow access without the need of Me.
There's a difference that i'd like to have for statics dimensioned on type-contruction level so that these are excluded here - come back for it later.

Do not worry into direction modules were not able to use the udts that we create inside of a thinbasic script. I will proove the opposite - also later...

for now all these udt-elements that are not static of any kind should be accessible with these names (no ME.-prefixing required -but still possible)
therefor it is either passing all of them with theirs names into any udt-function or create layovers onto these when entering any function of a type. Alternative
create a scope that keeps the layover valid and in place as long the udt-function that initially was entered does not disappear from that stacklevel where it was on entering the first called udt-function. the effort were "a bit more than the same" but performance were better in cases where udt-functions are calling udt-functions
on the same element (where me remains upon the same position in memory)

user defined local dimensioning of variables inside of an udt-function that matches an udt_Element-Name is only possible when the udt-scope where different from global and the udt-element-nameswill not be created as byref-passed variablesinside of a function - it would make these variables (as function parameters ) local to the function and that would take care of no duplicate variables automatic - (built in already!)

Layovers to the udt-members made ouside from udt-function-level but within type-scope will not prevent the user from dimensioning local variables with same names as udt-elements but it will find on access the local variables that have a matching sibling on udt-scope that to access Me were required again. i think the byref way could make the race- but perhaps i 've missed a detail
Example:


type tVec3dAlphaEx

X as Double '
Y as Double
Z as Double
Alpha as Double
Color_R As Byte
Color_G as Byte
Color_B as Byte
lFlags as Long


ok now all here has the choice:
when a type function is entered either get passed byref and all udt functions will receive a reference
or the names as here are dimda nsioned using dim xxx at varptr(me)+ udt_elementoffset will not go out of scope until the stacklevel goes once below the entering level