Just a quick tip for those that dive deep into the OOP pool, when defining you class members you have a few different Scopes and Accesses you can use.
Public – Can be read and written to from within the class or from outside the class instance.
Public Constant – Can be read and written to from within the class but only read outside the class instance.
Protected – Can be read and written to from within the class and any derived classes
Protected Constant – Can be read and written to from within the class but only read in derived classes
Private – Can only be referenced inside the class, it is completely invisible to the rest of the world
Global – A very special scope, it is actual reference by the class name not the instance. It value is global across all instances of the class
For example if you have a class named MyClass you might have code like this:
MyInstance is MyClass
MyInstance.Member = x
But if it is a global member you would reference it instance like this
MyClass.GlobalMember = x
Here is some example code from our NexMo Class
The issue comes when you have several different blocks of members, like our NextMo Class. If you define the PUBLIC CONSTANT block after the PUBLIC Block, for some reason the compiler decides that the members in the Global Block are also CONSTANTS and you can’t update them outside the class.
If you do them in the order of PUBLIC, GLOBAL, PUBLIC CONSTANT then the compiler thinks the members in PUBLIC CONSTANT are global and generates a compile error when you try to reference them with the instance name.
This issue has always been there, I have ran into it before, with needing GLOBAL to be last, but this is the first time I have also had PUBLIC and PUBLIC CONSTANT in the same class as well. Making it that much harder to figure out the correct order. I have created a small project and sent it to support as I feel this is a bug, I will let you know what get back.
If you would like the example project I sent to PCSOFT, so you can play with it yourself, here is a Dropbox link.
2 thoughts on “The order of you class members matter”
I got a reply back from Support and they will be updating the documentation with the following
It’s just that PUBLIC and GLOBAL do not cancel each other out.
// here we are in public instance
// here we are in global public
// here we’re in global private
// here we are in private instance
After working with this some more I have discovered the key is actually using 2 keyworks
Local or Global
Public, Private or Protected
Local Private = Private to Instant
Global Private = Private but applies to all instances (reference with class name not instance name)
Local Public = Public and specific to insant
Global Public = Public and applies to all instances