what is better : Global or Shared ?

[TI-994A]

Shared only works as it's intended with Defined vs Global and that's the ambiguity which isn't explained...

But SHARED works perfectly with or without DEFINE. And although redundant, SHARED works with GLOBAL as well.

Do you have a snippet to demonstrate this, or is it simply a suggestion for best practices?

[idle]

Shared only works as it's intended with Defined vs Global and that's the ambiguity which isn't explained...

But SHARED works perfectly with or without DEFINE. And although redundant, SHARED works with GLOBAL as well.

Do you have a snippet to demonstrate this, or is it simply a suggestion for best practices?

I could have sworn define made it work as I expected but it doesn't.

I really don't see the point of shared as it is as I have tried to explain from the onset shared is just a global, what does it achieve?

My expectation of shared is that it would share a named variable between procedures and be inaccessible in the global scope without a directive to get it or set it.
implementing shared as a namespace wouldn't take much effort, it just adds one more lookup in the global scope of the current module scope.

Code: Select all

Procedure ImplicitShare() 
  Shared x
  x = 123
  Debug "address of x " + Str(@x)
  
EndProcedure 

ImplicitShare() 

x = 234  ;the implicit share is made redundant as it's now global  

Debug x 
Debug "address of x " + Str(@x)
Debug "+++++++"

EnableExplicit 
Global y  ;added as global after Enable Explicit caught the error  

Procedure ExplicitShare() 
  Shared y 
  y = 123 
  Debug "address of y " + Str(@y)
  
EndProcedure 

ExplicitShare() 

y = 234  ;opps we made y global by mistake   

Debug y 
Debug "address of y " + Str(@y)
Debug "+++++++"

Define z  ;without define we will get an error with shared Z  

Procedure ExplicitSharedefine() 
  Shared z 
  z = 123 
  Debug "address of z " + Str(@z)
  
EndProcedure 

ExplicitShareDefine() 

z = 234 ;this should raise an error in my opinion but it doesn't why because shared is just a global it's not isolated or shared?       

Debug z   
Debug "address of z" + Str(@z)
Debug "+++++++"


;This is how I would expect shared to behave. ignore the macros    

Global xx = 1   ;declare a global XX 

Macro _Shared(x)  
  Global _shared_x
EndMacro   

Macro set_shared(x) 
  _shared_x  
EndMacro   
Macro get_shared(x) 
  _shared_x
EndMacro   

Procedure foo() 
  _Shared(xx)         ;create a shared variable in the global scope that's only accessible through in the named space of shared  
  set_shared(xx) = 2 
  ProcedureReturn get_shared(xx)
EndProcedure 

Procedure  bar() 
  _Shared(xx)        ;the vairable allready exists       
  set_shared(xx) = 3 
  ProcedureReturn get_shared(xx)
EndProcedure   

Debug xx ;the variable xx is Global and while it has the same name as the shared variable it's not in the "Shared" namespace 

Debug foo() 
Debug bar() 

Debug xx 

[AZJIO]

Code: Select all

Define z  ;without define we will get an error with shared Z  

Procedure ExplicitSharedefine() 
  Shared z 
  z = 123 
  Debug "address of z " + Str(@z)
  
EndProcedure 

ExplicitShareDefine() 

z = 234 ;this should raise an error in my opinion but it doesn't why because shared is just a global it's not isolated or shared?       

Procedure ExplicitSharedefine222() 
  Debug z ; returns 0 and therefore is not global
EndProcedure 
ExplicitSharedefine222() 

Debug z   
Debug "address of z" + Str(@z)
Debug "+++++++"

Did I do macro expansion correctly?

Code: Select all

;This is how I would expect shared to behave. ignore the macros    

Global xx = 1   ;declare a global XX 

Procedure foo() 
 Global _shared_x         ;create a shared variable in the global scope that's only accessible through in the named space of shared  
  _shared_1 = 2 
  ProcedureReturn _shared_1
EndProcedure 

Procedure  bar() 
  Global _shared_x        ;the vairable allready exists       
  _shared_1 = 3 
  ProcedureReturn _shared_1
EndProcedure   

Debug xx ;the variable xx is Global and while it has the same name as the shared variable it's not in the "Shared" namespace 

Debug foo() 
Debug bar() 

Debug xx 

[idle]

Did I do macro expansion correctly?

no, this is how it would appear in the assembly

Code: Select all

;This is how I would expect shared to behave. ignore the macros    

Global xx = 1   ;declare a global XX 

Procedure foo() 
 Global _shared_xx         ;create a shared variable in the global scope that's only accessible through in the named space of shared  
  _shared_xx = 2 
  ProcedureReturn _shared_xx
EndProcedure 

Procedure  bar() 
  Global _shared_xx        ;the vairable allready exists       
  _shared_xx = 3 
  ProcedureReturn _shared_xx
EndProcedure   

Debug xx ;the variable xx is Global and while it has the same name as the shared variable it's not in the "Shared" namespace 

Debug foo() 
Debug bar() 

Debug xx 

[AZJIO]

It has already been discussed that if a variable is declared global in a procedure, then an address in memory will be allocated for it and it will be global, but the assignment will occur during the operation of the function.
In this case, the variable is global and visible in other procedures. When using "Shared" (+Define) this does not happen, the variable remains unavailable in the procedures.

Code: Select all

EnableExplicit

Global x = 1

Procedure foo()
	Shared x ; it doesn't make sense even if there is no conflict.
	x = 2
EndProcedure

Procedure bar()
	x = 4
EndProcedure

Debug x
foo()
Debug x
bar()
Debug x

[idle]

If I define a variable in the global scope I would expect it to be globally accessible. Maybe my fractured mind isn't plastic enough to understand the reason for it being but it looks more like shared was added to fix the problem created by define rather than being added by design. To me It's like asking someone to stand in the corner of a round room!

If shared worked like my example that would make some sense to me and it would be a useful way to share properties between procedures, like to make a replacement for a vtable or such.

It appears shared is to protect against unintentionally using a global in procedure, but that doesn't makes much sense to call it shared as your sharing anything a global takes precedence over private and changing that behavior isn't logical as a variable is either global, private or static but if you wanted to add a new variable type called shared that you could in fact share among procedures so it's encapsulated or a property then yes that would be useful. with no side effects or ambiguity

Thanks for having the patience to point out how shared works.