Every PB source file should use EnableExplicit!

[kpeters58]

I was shocked to find that that is not the case ....

[fantaisie-software]

Well, the IDE code is somewhat old... Goodluck adding it :)

[tajmone]

@kpeters58, it would be great if you contributed to the IDE sources adding EnableExplicit everywhere! and I agree that it would be an improvement to the code quality (after all, the IDE has been bootstrapped since a long time, and can now be used to edit its own source code).

My only suggestion (since this would be a pervasive refactoring, affecting the whole codebase) is to create a separate long-standing branch for these changes (e.g. dev-explicit) so that the modified code can be thoroughly tested on all OSs before merging it into master branch — this, by the way, is how any changes to the code should be handled in general, and in the future the project will most likely define a formal strategy in this regard.

[kenmo-pb]

Agreed the IDE should eventually use EnableExplicit everywhere. I can help with that too.

Just be careful, because there are a lot of files / sections that are OS-specific. For example, I might get the project to build with EnableExplicit on Windows, but on Mac or Linux it might fail to compile because some other sections don't support EnableExplicit. That's more reason to pull into a feature branch and not directly into master.

[t-harter]

Its not that shocking if you consider that the IDE actually predates the EnableExplicit feature.

It is quite normal for a larger software project to still contain old code that has not been updated to use newer language features (you'll find code in the IDE/Debugger that still use allocated memory for data storage because Arrays/Lists in structures simply did not exist when they where written). Rewriting working code just for the sake of using a new language feature is just not worth the bugs that inevitable come with that.

I suggest to add it to new files and gradually introduce it in code areas that need to be updated anyways. Gradual changes are much easier to verify that sweeping refactorings.

[tajmone]

I suggest to add it to new files and gradually introduce it in code areas that need to be updated anyways. Gradual changes are much easier to verify that sweeping refactorings.

I totally agree, but we still have to find a way to actually test changes to the code base. Since we can't rely on CI tools like Travis (due to PB being proprietary software) we need to form a testers team which can check that the IDE compiles without problems on all three OSs — and, possibly, devise a way to test for features bugs somehow, manually or automated.

Currently, the risk is that a contributor adds/tweaks a features on a specific OS, oblivious of new bugs arising on other OSs. This is a tricky situation, and lacking automated tests at commit time, we need some testing protocol to prevent bugs from creeping into the official IDE package.

Any ideas?

PS: In this respect, I'd feel more comfortable if the repository were to offer official pre-compiled C binaries, to enable stricter testing conditions. Then, whoever wishes to re-compile the C components is free to do so, but testing should (IMO) be done using the same exact binaries that will go in the official build, to prevent differences in behaviour.

[t-harter]

To be honest, contributors only working on one OS is going to be a problem and it is not just about the testing. Writing good cross-platform code takes some getting used to and you only get better at that by actually developing on multiple (preferably all) platforms at least some of the time. It is of no use if people check in changes that work only on their preferred OS and expect others to work out the problems for the other platforms for them.

[tajmone]

Expecting all contributors to have access to all three OSs is going to reduce drastically the number of participants — especially if you also need support for 32-bit macOS and Linux, with the latest macOS and Ubuntu dropping support for it, which would require users to also have access to older versions of these OSs in order to test 32-bit builds.

It is of no use if people check in changes that work only on their preferred OS and expect others to work out the problems for the other platforms for them.

I agree on this, and I also think that discussing changes before implementing them would be a great start in that direction. This would prevent many common problems and dead ends, especially if people with expertise on different platforms would participate in planning code changes and new features, being able each to contribute insights regarding specific platforms.

In most open source projects covering multiple OSs that I've seen, only the core maintainers have the luxury of accessing all OSs at all times, with many contributors working mostly on their OS of choice. Good coordination is usually sufficient to make things work, although it might not replace experience of working on all OSs and writing code with that perspective (as you mentioned).

So, thinking in terms of one's favourite OS and merely expecting others to fix problems on other platforms is definitely not in the collaborative spirit; but relying on others' experience to collaboratively ensure that these changes work is quite OK (IMO at least).

The PB user base is not that huge, and even less so on GitHub. How many PB users have access to all three major OSs (and to SpiderBasic too) is anyone's guess.

I'm confident that the collaborative effort and experience might enrich everyone who participates (and few PB projects have the same traction has this one has), and that although it might not be as effective as selectively excluding contributors who don't regularly work on all platforms, it might pay in the long run in terms of invigorating the user base and lifting the collaborative spirit.

After all, this repository has opened the doors to an unprecedented collaborative experience in the PB community — which, IMO, has great outcome potentials in terms bringing people together and learning from each other. Needless to say, the old saying that "too many cooks in a kitchen slow down cooking" also applies here, but chances are that in the long term the benefits will outcome the shortcomings, because more minds at works on the same problems tend to always come up with better solutions.

[t-harter]

32bit vs. 64bit is no big issue for the IDE. The UI behavior differences between the operating systems are a much larger concern. I'm not expecting every developer to purchase a Mac, but I don't think it is too much to ask of a Windows user to set up a Linux VM to test out their changes if they want to be serious about contributing.