Absolutely right.
I have to, because the RC5 is only
one part (one cog in a larger "gear box").
To achieve the goal of a new VB, every part has to fit - and I have absolutely no doubt what
would happen, should I open the RC5 to the public now.
Baka for example would just love to "rip out" a few rendering classes, adding a few things -
then compiling his own "better version" (more oriented to gaming-scenarios) - and encourage
younger developers to use that instead ("look, it's much smaller than the original" - sorry Baka,
in case that hypothetical scenario is "too far off", but I don't think so).
The result:
Now we have a split code-base (with incompatible interfaces, bug-reports for one part not that easily
recognized and reflected in the other part).
Such effects will cascade - and the next young "game-developer" who is talented enough, will then
come up with "his own idea of nice gaming-widgets" (probably not even knowing, where 99% of the source
for his game-engine originated from, and that such Widgets already exist, in much better incarnations).
Then look at Eduardos comments, who's absolutely convinced that the RC5-Class-Interfaces are of "totally wrong design".
He would probably start to put RC5-Class-Code back into *.bas Modules, to be "more like original basic".
There we have the next scattering-effect - and the next set of incompatible "basically RC5-based" code-examples,
which will float around in the forums after some time.
Now, if the question arises "which GUI should we use, to implement a new IDE", some will probably
"vote" for "the Baka-engine" - some old-style guys who "never had some real use for Classes" -
will perhaps favour Eduardos approach to things, and so on.
As a result, probably nothing serious will happen - too much diversification, too many opinions
about "the right way to go about it" - well, that's the "FreeBasic having no decent GUI"-effect I was already mentioning.
In the end it all boils down to "stable interfaces" and "stable behaviour behind these interfaces".
That's what we rely on in our little msvbvm60.dll, and which enabled the community to "share
compatible sources".
The new compiler will have (in addition to the original VB-Runtime-Functions) a larger, modern Class-framework
in addition (RC5-based, because that is needed not only to support "modern-stuff", but to become platform-independent) -
a new IDE which aims to be portable between Windows
and Linux
cannot use Win32-APIs
(besides a handful of exceptions, separated by compiler-conditionals).
So, the platform- and system-specific APIs have to be "encapsulated away" in that Class-Runtime - and
it needs to be as stable as msvbvm60.dll is today (interface-wise and implementation-wise, the RC5 aims for that).
As long as that is not understood (and it obviously isn't by the majority of the VB-community), I have to keep
the sources closed (to maintain that interface- and implementation-stability which is needed in the long run).
Do you understand what I just wrote, or do I have to "murder even more words"?
Why do you even make such deprecatory statements in a thread which discusses the survival of the language you love and currently use?
What is your plan to ensure the continued existence of that language?
Are you willing to help people, who have already invested years to ensure its survival?
If you are not willing to help, fine by me - but then have at least the common decency to:
- not make any demands
- not join with those community-members who try to actively hinder the project in a "dog in the manger" like fashion
https://en.wikipedia.org/wiki/The_Dog_in_the_Manger
Olaf