Not a bad idea to collect information and opinions; it can help give a direction for the overall goals. Ultimately, the one doing the work (and the ones helping to support the work) make the final choice. I do recommend a small change first to get started. The most concise and obvious pull requests are the quickest to be reviewed and merged in.
For the 3 methods proposed, in my opinion, the real changes are the features that get added to the fbc manual. If the feature is added to the documentation, then that means that the feature is accepted by the developers, and will be continued to be supported, probably forever.
Juergen Kuehlwein wrote:1.) as is - add it as include file (definitions and run time code in array.bi). The features are available only, if array.bi is included. This makes everything acessible to the user.
fbc official distribution does not use this method for any of it's features currently. In this scheme, there's no real need for it to be part of the official distribution. It could be released as an extension, however desired, under whatever license desired, by whomever. Many community members release their contributions this way with great success. The main disadvantage is that the implementation is limited to official features. Adding a feature to fbc in this way would be a new method compared to what has been done in the past. We tend to avoid this method because, for example, if the implementation needs "crt/*.bi" then the user must also allow for "crt/*.bi" in every usage of the feature even if they are not directly needing "crt/*.bi". Plan on documenting everything exposed by the include file.
2.) add only the definitions to array.bi, and add the code to the runtime library, which still requires array.bi to be included for making the features available (just like file.bi). This keeps parts of the low level stuff away from the user
This is a common method that fbc currently uses for features. For example datetime.bi
and several other includes. The include file provides the declaration of the API, and fb (or gfx) run time provides the impementation. The main advantages of this scheme, is that only what is exposed to the user needs to be documented. The developers have some flexibility to change (or replace) internals without changing the public API. Functions are linked individually as part of the run time (do not need to be compiled every usage). The main disadvantage is that only a few users will ever look at the implementation as it currently written in C.
3.) add it to the compiler (new keywords etc.) and add the actual code to the runtime library, which makes an include file (array.bi) obsolete. This keeps all the low level stuff away from the user
This is a common method, but not the preferred method as it introduces symbol names to the global namespace. macros like LOWORD
and functions like LEFT
are automatically added to the compiler even though they are simple macros and function declarations. Only quirk keywords must be added to the compiler as there is no other syntax to declare them. I recommend against this method unless absolutely necessary.