Announcement

Collapse
No announcement yet.

Encapsulation of object instance variables

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Encapsulation of object instance variables

    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.

    Code:
    #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

  • #2
    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.
    Forum: http://www.jose.it-berater.org/smfforum/index.php

    Comment


    • #3
      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.
      hellobasic

      Comment


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

        Code:
        #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.
        Scott Slater
        Summit Computer Networks, Inc.
        www.summitcn.com

        Comment


        • #5
          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.
          [email protected]

          Comment


          • #6
            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.
            --Theo Gottwald
            ------------------------------------------------
            76706 Dettenheim * Germany * [email protected]
            ------------------------------------------------
            Joses Forum * Theo's Link Site * IT-Berater.org

            Comment


            • #7
              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.
              Chris Boss
              Computer Workshop
              Developer of "EZGUI"
              http://cwsof.com
              http://twitter.com/EZGUIProGuy

              Comment

              Working...
              X