In the XDEV magazine from July/August 2017 on page 71, Christian Schmitz writes basically that you might want to convert properties and methods in your App function (on a Mac) to a Shared Method. A shared method allows other classes to call that method without the class being uhmm initialized.
Why would that be an advantage to the App?
Would it also be good on a PC or Linux?
What are the disadvantages?
Is there any easy way to convert them other than just copy and paste?
What about shared methods and properties in modules? (Are they uhmm already shared?)
There also seems to be a good discussion here:
Shared Methods: Protected
The text is below:
[quote]The app function in Xojo is quite slow. The implementation
I expected personally was a simple read-only global variable.
Thats how the Cocoa frameworks handle NSApp. When the app
starts, this variable is initialized, so before initialization in a
Cocoa app in Xcode, NSApp can be nil. For Xojo, the app function never returns nil except inside the App. Constructor. Due to the App function being a function, it does some things for the runtime and costs time.
Properties and methods de ned in the application class accessed via the app function have a perfor- mance hit due to the app function itself. My recommendation is to make those shared methods and
shared properties whenever possible. The access of a shared property on the app class is about 20 times faster than going though the app function for a regular property.
Be aware that once you are inside a method (or event) in your app class, accesses to properties should go without app. prefix. Simply without or with self. prefix, you can quickly access other properties or methods.[/quote]
There are a few standard cases where a shared method is advantageous:
- As a named constructor (AKA a “factory” method). If your class has several constructors it can be useful to change them into shared methods with more useful names. (e.g. BinaryStream.Create)
- As a callback function to a DLL/so/Dylib. Callbacks can’t be ordinary class methods. They can be module methods or shared methods, but module methods don’t have access to the private methods and properties of the class.
Yes, they work the same on all supported platforms.
- A shared method can’t access non-shared methods or properties of the class unless it has a reference to an instance of the class.
- Shared methods are not virtual. This means they are slightly faster since there’s no dispatching overhead at runtime.
Right-click the method and choose “Convert to shared” or “Convert to regular” to change back and forth.
Shared methods and module methods are both static and non-virtual. The difference is that shared methods can access private methods and properties of the class it belongs to.
Thank you very much. From what you wrote, I have no reason to convert my methods.
What about properties? Is it worthwhile?
App itself is a slow function.
Calling app.SharedMethod is much faster than App.Method.
Please read article carefully.
Thanks Christian. That probably explains why my little program drags when I start it.
To be honest, abusing shared methods for the sake of performance is a real nogo for me. Shared methods have 1 purpose: Do things that aren’t instance related.
There are no advantages or disadvantages to use shared methods, only right use cases.
Sure, but what about app class?
You only ever have one instance, so whether your property there is shared or not, doesn’t matter except for performance.
Thank you Christian. Matthias answered the other question I had about the disadvantages and it is simply hard to manage. I very much like increasing the App speed