Encapsulation of object instance variables

[Charles Dietz]

I was disappointed to learn that INSTANCE variables in an object do not override GLOBAL variables of the same name just as LOCAL variables in a function do. It seems to me that the concept of encapsulation is violated when an INSTANCE variable can be accessed from the outside by simply adding a GLOBAL declaration to it.

I was hesitant to post this observation since I'm sure it will expose my ignorance of the new PowerBasic classes and objects... but my curiosity got the best of me. I'm hoping for some reflections of others on this topic.

#DIM ALL

GLOBAL counter AS LONG

CLASS cTest
   INSTANCE counter AS LONG

   CLASS METHOD CREATE() 'constructor
      counter = 40
   END METHOD

   INTERFACE iTest
      INHERIT IUNKNOWN
      
      METHOD incrCounter()
         INCR counter
      END METHOD
   END INTERFACE
END CLASS

FUNCTION PBMAIN()
   LOCAL oTest AS iTest
   LET oTest = CLASS "cTest"
   'counter = 100   'this will change the object's counter
   oTest.incrCounter
   MSGBOX STR$(counter)  'access to objects's counter
END FUNCTION

[José Roca]

You're not accessing the instance variable from outside. What is happening is that the class is ignoring the instance variable and working with the global variable. Change INSTANCE counter AS LONG to INSTANCE counter AS STRING and you will see that the compiler doesn't complain unless you rem the global variable. You should report it to PowerBASIC.

[Edwin Knoppert]

Similar to static's as i heard.
Two instances may share the same static variable?
If so, a serious no-no imo.

I avoid statics anyway but sometimes easy.

Not overiding anything from the outside should not happen(like the global issue).
A class should be self contained.

I haven't tested both scenarios though.

[Scott Slater]

Declare the GLOBAL after the class definition, then it will work as you wanted it to.

#Compile Exe
#Dim All
 
Class MyClass
 
   Instance i_Dword  As Dword
   Instance i_Dword2 As Dword
   
   Interface MyInt
      Inherit IUnknown
      
      Property Get iDword As Dword
         Property = i_Dword
      End Property
      
      Property Set iDword(ByVal InVal As Dword)
         i_Dword = InVal
      End Property
      
   End Interface
   
End Class
 
Global i_Dword As Dword
 
Function PBMain () As Long
   
   Local MO As MyInt
   
   MO = Class "MyClass"
   
   MO.iDword = 89
   
   ? Format$(MO.iDword),,Format$(i_Dword)
   
   MO = Nothing
 
End Function

I still think the Instance variable should have precedence over globals of the same name just like SUBs and FUNCTIONs do.

[Petr Schreiber jr]

I reported this issue to PB team few days back,

the way it works now goes little bit against the encapsulation concept, you could never predict in which case the class will work with instance and when with global, moving CLASS from project to project.

[Theo Gottwald]

This was the "first strike" with PB and CLASSes, and for this it was remarkable bug free.

Now we got this small issue, which you can ovrcome, by simply adding a prefix "G_" before any of your Global variables.

Besides that i also think in a new PB version the Instances should have precedence over the GLOBAL.

While such equal Variable names is generally a potential source of trouble.
And should be avoided.

[Chris Boss]

I have found that it is not a good practice to define global variables using names which may be common to local variables.

Personally, I prefer to define global variables with some kind of consistant prefix so they stand out.

ie.

GLOBAL App_Somevar as LONG

You can use any prefix that makes sense to you like:

g_
glb_
app_

Anything that makes sense to you.

I use App_ to stand for application wide global variable.

One needs to be able recognize global variables at a glance or one may introduce all sorts of errors.