PureBasic Forums - English

This is not (yet ) a request, but I would like to poll the opinion of the other PureBasic users on two topics: pre-processors and user libraries.

Pre-processors.

Some of us like pre-processors (to do OOP stuff, introduce multiline capabilities, have numbered backups, etc.). Currently, the only (comfortable) way to use them is to piggyback them on the compile/run and build functions inside the IDE..

Wouldn't it be a good idea if you could, inside the IDE, specify a list of pre-processors, which would be executed one after the other before the (processed) source is passed on to the compiler? Best would be if each pre-processor could be turned on / off, just like the tools we can specify in the tools menu.

I'm not sure if this should be handled inside the tools menu (and apply to any and all code), if it should be saved per file, or if it should be included in the source and be keyword driven. (Hmm. Interesting idea, the latter. I may expand CodeCaddy to allow us to do preprocess chains if people are interested. It's actually pretty easy, come to think of it, strip out $PreProcessor <name> keywords and stick them in a list, then call the different preprocessors one after the other...)

Would it be worth it, and what would make sense?

User libraries.

I am NOT much of a fan of user libraries, for two reasons:

1. they are version dependent, and
2. they may conflict with other user libraries or your code

So, obviously, I'd rather include source code, not libraries. (Are there any advantages of using libraries over includes, by the way? Except for speed, is there some other reason to use them?)

Throwing a bunch of libraries into a folder, upgrading PureBasic, and hoping things will stay running is a recipe for disaster. Would it make sense to allow the inclusion of libraries selectively, by ticking options in a menu? Would it make more sense to include them using a keyword UseLibrary like we use IncludeFile, or should (could) a preprocessor be used to shove them in and out of the user libraries folder? (That's a bad idea as it would disable info in the editor, as well as slow down the process, I know.)

I'm NOT trying to raise a flamewar or something similar, I'm honestly interested in people's opinion (so don't go and tell somebody else he / she smells like a dead fish and his / her reasoning is flawed, that both may be true but the first argument should be ignored (we all have different tastes when it comes to deodorant) and the latter needs substantial arguments boyound the 'dickhead / you stink' level...

I hope I didn't just launch a troll-snack...

blueznl wrote:User libraries.

...

Would it make sense to allow the inclusion of libraries selectively, by ticking options in a menu? Would it make more sense to include them using a keyword UseLibrary like we use IncludeFile, or should (could) a preprocessor be used to shove them in and out of the user libraries folder? (That's a bad idea as it would disable info in the editor, as well as slow down the process, I know.)

How would selectively enabling a library solve any of the issues present with PureBasic updates ?

Having the ability to select order and enable available pre processors would be quite useful, could it be achieved as a separate utility to group the pre processors?

Uselibs the version issues can be a bit frustrating, it would be better if we could just use standard libs that got dynamically wrapped, though I guess it would have been done if it could have been done already.

freak wrote:

blueznl wrote:User libraries.

...

Would it make sense to allow the inclusion of libraries selectively, by ticking options in a menu? Would it make more sense to include them using a keyword UseLibrary like we use IncludeFile, or should (could) a preprocessor be used to shove them in and out of the user libraries folder? (That's a bad idea as it would disable info in the editor, as well as slow down the process, I know.)

How would selectively enabling a library solve any of the issues present with PureBasic updates ?

It would not, but it would solve any compatibility issues between code and libs, or between libs and libs.

It would not solve compatibility issues, I'm aware of that (I'm not a big fan of userlibs anyway Never grasped the advantage of user libs over includes.)

idle wrote:Having the ability to select order and enable available pre processors would be quite useful, could it be achieved as a separate utility to group the pre processors?

I'm envisioning something like this...

Code:
The IDE would then take this code, and store it in a temp file temp.$$$ as:
... then it would first execute 'codecaddy.exe temp.$$$'...
... and then it would execute 'oopparser.exe temp.$$$'...
... and then it would pass the resulting temp.$$$ on to the compiler...

I'm considering adding such an option to CodeCaddy, but it would be better if this would be part of the IDE. It's not that hard to add so I guess I'll simply do it if I feel like it I just think it should be part of the 'production chain'.

A byte mark of some kind that identified the library version would certainly facilitate the automation of this type of feature. For example, incompatible and conflicting libraries are disabled by default.

blueznl wrote:I'm considering adding such an option to CodeCaddy, but it would be better if this would be part of the IDE.

Good idea IMHO. Could be very useful for certain projects.

Regards, Little John

Mistrel wrote:A byte mark of some kind that identified the library version would certainly facilitate the automation of this type of feature. For example, incompatible and conflicting libraries are disabled by default.

I wonder how such a detection mechanism should work though.

I'm somewhat incliced towards a Library statement, similar to an include statement, but where the Library statement has some sort of version indication? Then again, that would not help to identify conflicting libraries, unless each library would come with an exclude / incompatibility list... argh... Sounds to me like an enless pit of troubles.