I suppose this is something I should know already…
I’ve subclassed all the controls, and they all implement the same interface. As far as the rest of the code is concerned, all controls look the same. All the these controls live in a folder.
Now, let’s say I start a new project. I copy the folder with all the controls to the new project. Let’s say the new project does not use a popupmenu or textarea. Will these be included in the built app (even though they’re never used), or does the linker strip them out?
Well, classes, windows or stuff in modules gets stripped out if not used.
But e.g. methods of classes are always included, because you may call them via Introspection.
Thanks. That what I thought.
In the IDE, Project menu > “Analyse Project” will warn you of stuff that isn’t used…
Would it make sense to request a switch (per project) to disable introspection support so these become also omitted?
I never use introspection (up to now), but there are sometimes classes I keep in a project for legacy purposes (e.g. references or to know how I did something in earlier versions). Those should not need to be included in the built app, and it makes the app even bigger.
A switch to turn off support for introspection would be welcome. Of couse, I’d imagine a IntrospectionNotAvailableException when attempting to use introspection with the switch off.
But is it worth thinking about it?
I logged a variation of this back in 2018.
I’ll subscribe to that case. Thanks.
But since Norman and Greg both left the company, who inherited that case?
Is is possible that use of MBS functions may involve introspection (on the caller’s Xojo app)?
That is, even if the developer is not using introspection directly (and my guess is few are), is it possible for a MBS function to be doing it behind the scenes and thus still need this data?
I don’t think that our plugin can trigger something in this direction.
We can ask the IDE for a method pointer via plugin SDK APIs.