Is there a #Pragma or other conditional for duplicated methods?

General
1

I have started “containerizing” a number of my shared code to make sharing less labor intensive.

However, if I have a duplicated method in multiple shared objects, I run into the collision issue on compile.

Before I start removing pieces that will need to be replaced in other projects later, I was wondering if there was a conditional flag like we have in C/C++ to ignore a method if the method’s signature is already included.

2

None
You get the compiler warning then go use the compatibility flags to make one only compatible with a platform you’re not targeting and carry on
That way you can keep them but they wont get included

3

And … since we can’t know the order of the build, we can’t pre-set a variable in a master global module and then wrap the containerized methods with a #if Not DEFINED_METHOD_VAR …

Hmmm, more thought on this tonight.

4

you have no option to put code outside the declaration of the method anyway

theoretically you’d like to do

#if disabled
    sub foobar()
    end sub
#endif

but there’s no way for you to do that

5

You can hide a method using Inspector / Gear Icon/ Include In… and deselect one or more platforms you are working on. Would that help?

6

Thats exactly what I mentioned earlier - compile - switch flags, compile, switch more flags and keep going
Thats as close as you get

7

That’s the same thing that Norman suggested above. It is a workaround, but it’s a hack. What I’ve done is to make the method Protected to the containerized code. That allows it to work in the test jigs for the containerized code, but not interfere with the master globals module.

8

Just curious why you consider it a hack?

I use it all the time when I’m moving code over from OPC to something more reasonable. I like to keep the old stuff around in case there are specific details hidden inside the methods, but I disable them with compile flags to follow the errors around.

9

Any time that I must modify settings for each build instead of providing a stable set of parameters across the code, I consider it a hack.

For example, the BRU engine code is written in C and ASM. It’s 128K lines of code in 121 modules (.c, .asm, .h). It compiles on 21 different Unix and Windows platforms with NO changes.

10

(oh, and hack doesn’t mean bad, just not the cleanest mechanism for accomplishing a task)

11

Oh okay, per build type, it’s a different situation I guess :slight_smile:

12

[quote=320557:@Tim Jones]Any time that I must modify settings for each build instead of providing a stable set of parameters across the code, I consider it a hack.

For example, the BRU engine code is written in C and ASM. It’s 128K lines of code in 121 modules (.c, .asm, .h). It compiles on 21 different Unix and Windows platforms with NO changes.[/quote]
How many #if’s (#ifdef etc) in it ?
I’d expect a pile (or the projects to build them exclude them as part of the project config)

I wouldn’t call it a hack - it’s basically xojo’s way of making it possible to do what #ifdef does in C allowing you to conditionally compile some methods for one target or another

Not much different than in each method using #if Target just that you can include exclude entire methods modules per target

Which is basically what you asked for

13

Yes - lots of #ifdef #ifndef code - BUT I only need to write it once.

The good news is setting the duplicate methods within the containerized modules to Protected solves this particular issue.

14

Sure
In Xojo IF you were writing code from scratch you’d use one method and inside it use #if Target’s to run the right code
But thats not what you’re doing

I expect you would be shoving in all kinds of #ifdefs around code in C if you were doing about the same there

15

In C, I’d define the methods and do something like this:

#ifndef THIS_METHOD_DEFINED // only include the following code if it's not defined #def THIS_METHOD_DEFINED // define it ... Stuff in method #endif

That would allow multiple inclusions of a module’s contents (such as stdio.h) without the multiple inclusions from stepping on one another. Only the first inclusion of that wrapped code would be compiled into the final object code.

What I’m asking for in Xojo is slightly different in that I’m not trying to segment platform builds, but rather to limit the collision of two methods with the same name and signature.

16

Thats why I said way way way back

[quote=320512:@Norman Palardy]None
You get the compiler warning then go use the compatibility flags to make one only compatible with a platform you’re not targeting and carry on
That way you can keep them but they wont get included[/quote]

[quote=320539:@Norman Palardy]you have no option to put code outside the declaration of the method anyway

theoretically you’d like to do

#if disabled
    sub foobar()
    end sub
#endif

but there’s no way for you to do that[/quote]

17

Right, but the Protected flag prevents the global method/signature from competing and colliding with the containerized method/signature in the larger projects while allowing the containerized version to run as expected in the test jigs I’m creating for the testing of these modules.

Thus, I have a workaround that is better for what I’m trying to achieve than switching platforms on and off.