The order of you class members matter

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

  1. 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


  2. 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


Leave a Reply to Pete Halsted Cancel reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s