I have several custom controls that I’ve accumulated over the years. Many of these use External Methods (more so than Declares). Many of these External Methods were gleamed either from Sam’s excellent AppKit product or other sources or repos posted here in the forums.
Up until now, I’ve had a single central module that the External Methods are attached to. They used to be all mostly Global scope, but recently I changed them all to Protected to minimize my globals.
What I’ve been doing makes sense, until I start a new project and want a few (but not all) of the custom controls. I copy them into the new project, then have to painstakingly copy each required External Method.
Note: I’m not using External Items, just because.
My question is whether there is a downside to copying each custom control’s required External Methods to the control itself (and making them Private), verses maintaining a central module that shares all the same Protected External Methods?
The central module approaches means there is just one declaration of a given External Method, e.g., NSClassFromString.
The Private to each custom control approach means there could be multiple declarations of NSClassFromString in the project.
Is there a downside to the Private External Method approach? Like, is the compiled project slightly larger, and/or can this affect performance?
The personal benefit I see is making copying custom controls between projects much simpler (just one object, verses many).
Well, there’s probably not a lot of downside to what your’e suggesting assuming those system calls aren’t changing very often. Generally, we developers try to minimize our code duplication because it increases the cost of maintaining the code. It’s a very good rule of thumb that if you use a code in more than one place, you should be keeping a single copy of that code and calling it from multiple places.
But that’s just a very good suggestion and not the law. If you find that these little snippets of code are very static over time, and you don’t run into dependency issues or namespace conflicts… then I say go for it if you find enough upside.
Thank you for commenting @Eric_Williams and I agree about code duplication. My OCD keeps me hyper aware of consolidating code logic into one reusable place as often as I can.
But, on the other hand, I see an External Method more as a placeholder or switch to access a function outside of the app. So there’s not a lot of code to maintain, except of course if Apple decides to change their API names or location - then I’m hosed
Having the required External Methods local (and Private) to my custom controls does make copying between projects much easier, and definitely a time saver for me. I guess it would also make using External Items again easier, too.
I suppose I could just get in the habit of writing Declares more often, but is that just six-or-one-half-dozen-of-the-other? At least an External Method only has to be declared once on a control, verses potentially duplicate Declares statements, depending on the need.
I do everything using Declares. I find it easier if all of the definitions of the things I’m using are right there in the method I’m using and there’s no external dependencies beyond the classes themselves.
In terms of putting things like NSClassFromString (which along with alloc and init are used all the time) into a Xojo method, it’s tempting, but calling a Xojo method does have some overhead, however small, that can add up over time.
Just my 2 cents.
If you’re doing a lot of declare work, I suggest using my translation scripts. They’re not but close enough that you can fix them if necessary.
Yes, I noticed. Your excellent macOS Toolbar for Xojo is a great piece of work, as well as a learning experience. In part, looking over your code is what sent me down the road that led to posting my question. @Martin_T’s StackView project is built similarly, except with more External Methods.
@Greg_O, just to be clear, are you saying that using a series of Declares within a Method or Event has potentially less overhead, than calling the equivalent number of External Methods?
They shouldn’t be. The tricky part is making sure they don’t cause problems in cross platform apps.
A very long time ago (I honestly don’t remember when) I had to convert a project that was originally only macOS and which used an external methods to one that could be built for Windows. At that time, I got so many compile errors that I stopped using them and never looked back.
but close enough that you can fix them if necessary.
