Initialize values in a module?

Hi all,

I have a module which has an array of custom classes as a property.

I know I can initialize the array in the app.open event, or call an init method in the module, however I would like to keep EVERYTHING related to the module in the module.

Given that modules are not objects but are still logical holders of global methods and properties, I know it is technically possible to add constructor/destructor functionality to initialize properties. That would enable you to have self contained modules with initialization.

Has that been implemented/changed in Xojo?

As I’m still on Snow Leo I can’t run the latest versions of Xojo. I think there was a feature request once but as I no longer have access to feedback (requires 10.7 now, tal) I can’t check that either.

TiA

Markus

The best you can do is add an Init method to the module and a private property like hasBeenInited As Boolean. Every method that needs a property that must first be initialized will call Init, and the Init code would look like this:

if hasBeenInited then return

// Initialie the props

hasBeenInited = true

Thanks Kem, that’s what I thought.

Would be nice if Modules could auto-initiate, that way you can just copy&paste a module into a new app and don’t worry about forgetting to initiate it in the app.Open event.

  1. Make the array private and rename it. You could for example prepend it with an “m”, like in mArrayOfCustomClasses.
  2. Create a public function to access the array from the outside:

Function ArrayOfCustomClasses() As CustomClasses() Static initialized As Boolean = False If Not initialized Then // Initialize mArrayOfCustomClasses here initialized = True End Return mArrayOfCustomClasses End Function

Markus, Kem’s suggestion does not require you to do anything in app.open. It is fully self-contained.

It still requires me to call the init method from somewhere.

What I’m looking for is equivalent to defining some constants or methods in a module - they are simply available when you copy the module to a new project.

Think of the cursor module. The Cursors module contains a library of standard mouse cursors that you can access by calling System.Cursors.MouseCursorName like this

Me.MouseCursor=System.Cursors.HandOpen

You do not need to initiate any of the cursors nor call an init method. I would gess that the cursors module gets initialized somewhere as well, but it would be cool if modules became truly self-contained.

It is a property called “Cursors” in the module “System”. See my example above on how to implement it.

Markus, look at the Singleton pattern. I think there is an example for this in the package.

The basic idea is to use a class instead of module, but create a shared method that returns a single instance of that class. Since there will only ever be once instance, it will work as a module does, but the initialization can take place in a private constructor.

In Xojo singletons don’t make sense - use a Module for that (see my example above on how to initialize a property in a module). With a singleton you are doing nothing else than mimicking a module (in a more complicated way).

Singetons make plenty of sense in Xojo, and solve his probem quite neatly. It ensures that the only way you can get a copy of that class is to call a method that creates and initialilzes it. If the method gets called again, it just returns a reference to the first created instance.

As you may be able to tell, I’m in Jared’s excellent Design Patterns session at XDC.

Yes, it’s very obvious.

That’s called a Module in Xojo. Module ? one instance of a class.

But minus the constructor and destructor…

True, but you need to call a shared method on the class to have the constructor executed (usually called “GetInstance” or similar), so why not have it all in one function in a module? Unless of course one thinks, one day one might need two or more instances, but then it is not a singleton and if for the moment you need just one instance of a class, create only one instance and hand it over to each object which needs to access it in their constructors.

The destructor will only be called when the application quits, because with a (proper) singleton you cannot set the one instance to nil - if you do, the shared method “GetInstance” will create a new instance on the next call, which will not be the same as the first one and therefore violates the whole idea of a singleton.

Singleton is probably the most overrated design pattern. I was a big fan when I read the GoF book in the 90s and I used singletons everywhere. It was a mess, like global variables are a mess (actually the singleton is a global variable through its shared GetInstance method).

I agree with Eli,

Singleton are considered as bad practice, but you may add: except when they are hidden.

Using a Singleton inside your Module and hidden from the outside (private), for the sole purpose of internal initialization may be convenient.

Perhaps this is one of its usage that is still very valid. In this case it is just a way to implement lazy initialization instead of having a bunch of If m_init = True Then …, or Static etc… everywhere. Just make sure the user of the Module never has to deal with the Singleton directly.

But if you think further about it:

In your Module you may have a Private Method like GetMyObject() As MyClass ( instead of MyClass::GetMyInstance() ). But then, what happens inside that Method ? Well it will check if the object instance already exist, if not it will create an instance of your Class and return it. But here, where is the Singleton ? In fact there is none.

Having MyClass::GetMyInstance() is, ultimately, just a ‘decoration’ to retrieve the instance. Having a Method GetMyObject() will do exactly the same without polluting the Class itself.

So what Eli say makes perfect sense, as long as the Module user never see/use that Class nor that GetMyObject() Method directly.

Cheers,
Guy.