FreeBASIC Namespace Project

[Imortis]

So, As I am currently working on converting the freeBASIC Runtime library to freeBASIC from C. After I have converted the whole thing and can confirm it is working, I would like to start adding the RTLib functions to a Namespace. The reason for this is that it would greatly clean up the global namespace, allowing more words to be used as variable names, function names, etc.

The downside is that some code would have to be added to use the namespace to make code compile on both new and old versions of FB, similar to what we do with fbGFX2.

My thought is we should go all the way with this: Add all gfx functions to a namespace, instead of just a few types and enums, like we ave now. He is my proposal for the Namespace layout:

FB.STD - This would be the Runtime library.
FB.GFX - This would be the graphics library.

For now, I feel that is all we would need. As new features are added to the languange (sound, network?, gui?), they could be added to their own namespaces. This would make it easier to extend the language with out muddying the global namespace, and it would make it easier for people concerned with exe size to see exactly what libraries are included in the compliled exe, but by looking for the namespace markers.

Thoughts? Suggestions? Complaints? Cookie Recipes? All are welcome.

[dodicat]

Compliants section.

Using namespace std.
c++ surely

I can pick up code from early fb , 2006/7/8 ...
It runs like a dream usually, in 1.05.0.

So now we will have thousands upon thousands of lines of code on this forum which will not compile with this new fb.
What about all the code not on this forum.
(Rosetta code for example, where FreeBASIC is promoted)
Cast to be non runners for the sake of a tidy up.

Who uses fbgfx2
I only have fbgfx.bi.

Namespaces for new things then yes.

[Imortis]

Just as a note: I am not trying to argue with you on this. I asked for complaints and criticism. I just want to explain why these were my suggestions. If others can put forward better suggestions that would accomplish the same things, I am all ears.

...
Using namespace std.
c++ surely
...

I suggested STD because it is simple to type and most people could remember it as "standard". It has nothing to do with C++. Even a broken clock is correct twice a day.

...
I can pick up code from early fb , 2006/7/8 ...
It runs like a dream usually, in 1.05.0.

So now we will have thousands upon thousands of lines of code on this forum which will not compile with this new fb.
What about all the code not on this forum.
(Rosetta code for example, where FreeBASIC is promoted)
Cast to be non runners for the sake of a tidy up.
...

People complain that the compiler is stagnant, but no one wants to make any changes to make it fresh. Don't get me wrong, I don't super like the idea of my old code no longer working, but if one of the major complaints about FB is "too many keywords in the global namespace", maybe we need to deal with a bit of hassle for the language to move forward.

...Who uses fbgfx2
I only have fbgfx.bi.
...

The official name for the freeBASIC graphics library is: FreeBASIC Graphics Library 2, or FBGFXlib2. fbgfx.bi is part of the same thing.

... Namespaces for new things then yes.

Noted. Thanks for the input.

Ultimately, I want the compiler to be much more maintainable by FB users. I want to remove as much C code a possible so changes and updates don't require a massive build process. I want to make it so that the whole language is as easy to work on as possible.

While I feel that some of these changes would be a pain in the butt short term, long term they will have a massive benefit to the language as a whole.

[sancho3]

I like the namespace idea.
Would it not be possible to add a language option? This would keep fb from orphaning the existing code.
Something like:

Code: Select all

#lang "FBStd" - option to use the FBStd library.  

[paul doe]

...
So now we will have thousands upon thousands of lines of code on this forum which will not compile with this new fb.
...

The solution can be as simple as adding an 'using' statement at the top, as in 'using fb.gfx' if the code uses the graphics library, for example.

People complain that the compiler is stagnant, but no one wants to make any changes to make it fresh. Don't get me wrong, I don't super like the idea of my old code no longer working, but if one of the major complaints about FB is "too many keywords in the global namespace", maybe we need to deal with a bit of hassle for the language to move forward.

Totally. FreeBasic is currently mature enough so as to finally do things its own way, instead of worrying about supporting old stuff. I don't like the idea also, but I understand that this is a necessity of the times, too.

Ultimately, I want the compiler to be much more maintainable by FB users. I want to remove as much C code a possible so changes and updates don't require a massive build process. I want to make it so that the whole language is as easy to work on as possible.

This is a powerful idea, and a big step forward. I hope it gains all the traction it deserves.

While I feel that some of these changes would be a pain in the butt short term, long term they will have a massive benefit to the language as a whole.

Then again, they all are. I still remember the pre 0.24 days, in which you had to update your code on an almost weekly basis. It was a rollercoaster ride, but the result was well worth it.

This is another step in the right direction (as is porting the RTL to native FB), so I fully support it.

[paul doe]

I like the namespace idea.
Would it not be possible to add a language option? This would keep fb from orphaning the existing code.

It's possible, of course, but this adds complexity. I think that Imortis idea is to streamline the language, not segregating it even more.

[Tourist Trap]

I like the namespace idea.
Would it not be possible to add a language option? This would keep fb from orphaning the existing code.
Something like:

Code: Select all

#lang "FBStd" - option to use the FBStd library.  

Many people have already stated that they would like to have a tidy, tiny, very core version of fb, and being able to link whatever extra as libs, just like in C finally. This was not totally fool, since there is a potential niche for FB on embedded systems (those would maybe be happier with a mini fb).

This all to say that I would vote for a new lang option, such that "fbmini", "fbcore", "fbstd", or whatever version that would reorganise everything, but with some theme in mind. This could be then to provide a kind of min fb, with modules, and everything in namespaces. By the way this would potentially be a good starting point for future candidates to expansions. The principle of starting from a small core doesn't make the language easier to use, but certainly easier to expand in any direction.

But this is still useful to have a language that gives you a package of stuff in one well choosen block, provided that this block is gem stone.

Ok that's just my peasant opinions ;)

[angros47]

So now we will have thousands upon thousands of lines of code on this forum which will not compile with this new fb.

The worst is, the compiler itself would be one of those pieces of code

The solution can be as simple as adding an 'using' statement at the top, as in 'using fb.gfx' if the code uses the graphics library, for example.

Not so simple, unless it were possible to use two default namespaces at the same time (and it isn't, since one "using" voids the previous one): in fact, commands like CIRCLE would be under the graphic namespace, commands like OPEN in another. Also... how to deal with commands like GET and PUT, that have different meanings (File I/O and graphics)?. Under which namespace would you put LINE (used in LINE INPUT and in graphics?)

[Imortis]

...The worst is, the compiler itself would be one of those pieces of code...

The compiler, from what I have seen, calls every function like that from it's internal name, not with the exposed version. So nothing would have to be changed in the compiler, I think. I have not looked at ALL of the code in the compiler, but what I have follows this convention.

...Not so simple, unless it were possible to use two default namespaces at the same time (and it isn't, since one "using" voids the previous one): in fact, commands like CIRCLE would be under the graphic namespace, commands like OPEN in another. ...

This is true, and I can see that this could be an issue. Maybe the USING command needs to be changed to allow multiple namespaces?

... Also... how to deal with commands like GET and PUT, that have different meanings (File I/O and graphics)?. Under which namespace would you put LINE (used in LINE INPUT and in graphics?)

File I/O would be under the rtlib Namespace, and graphics would be under the fbgfx Namespace. They are not the same function being called in two places, they are two different functions that the compiler has to disambiguate based on which params you pass it. If these calls were separated into different namespaces, it would be easier on the compiler to tell the difference. If we did set up USING to work with many namespaces, then it could just fall back on the old process to figure out which one to run.

Line Input is a special case because it uses QB quirks to even be processed. Once again, the internal name for that function is not the same as the one for the Line function.

[angros47]

I read now that in C++namespaces are additive, and can be used at the same time with multiple USING. Is the same true for FreeBasic, too?

[paul doe]

I read now that in C++namespaces are additive, and can be used at the same time with multiple USING. Is the same true for FreeBasic, too?

Seems like it:

Code: Select all

namespace n1
	dim as integer foo = 1
	
	namespace n2
		dim as integer bar = 2
	end namespace
end namespace

using n1
using n1.n2

? foo
? bar

sleep()

Commenting either 'using' makes the code choke. With unnested namespaces is the same thing:

Code: Select all

namespace n1
	dim as integer foo = 1
end namespace

namespace n2
	dim as integer bar = 2
end namespace

using n1
using n2

? foo
? bar

sleep()

[angros47]

Well, this makes things simpler. In theory, if by default the runtime and graphics namespaces are enable, no existing code would be broken. Perhaps a way to deactivate the namespaces active by default could be provided (like it's possible to disable a single keyword with undef)

But this leads to the real question : Imortis. .. do you know how to patch the compiler to add this feature? Are you willing to try and test it? Because I think that unless we have a test version, there is no point is theoretical discussion

[Imortis]

...But this leads to the real question : Imortis. .. do you know how to patch the compiler to add this feature? Are you willing to try and test it? Because I think that unless we have a test version, there is no point is theoretical discussion

I have not looked at the namespace part of the compiler to even see if it could be done as implemented. I have no doubt that I could understand the code in question given enough time. The compiler portion is written in FB, which I am proficient in. Also, the only reason you are asking for this is so you can have a "default" namespace, which kind of defeats the purpose of putting the keywords into namespaces in the first place.

We have two sides of this debate: Those who think the current global namespace is already too crowded so argue against any addition to the compiler, and those who just want their old code to continue to work with out edits.

I understand and and even sort of agree with both sides, but for the compiler to grow in any meaningful and useful way, someone is going to have to be disappointed.

The purpose of this thread is to try and get as many sides of the argument as possible from as many users of the language as possible so that a suitable path/compromise/whatever can be chosen.

No choice is indeed a choice. It just happens to be a bad one.

[Tourist Trap]

We have two sides of this debate: Those who think the current global namespace is already too crowded so argue against any addition to the compiler, and those who just want their old code to continue to work with out edits.

I understand and and even sort of agree with both sides, but for the compiler to grow in any meaningful and useful way, someone is going to have to be disappointed.

The purpose of this thread is to try and get as many sides of the argument as possible from as many users of the language as possible so that a suitable path/compromise/whatever can be chosen.

No choice is indeed a choice. It just happens to be a bad one.

[/quote]
Just from this what is said here, I still don't see what's the problem in dividing fb into 2 branches as stated by sancho3, one with the compatibility, and the other with the reshape. Python which is really considered a clever tool has maintened a 2.7 branch despite a major reshape allowing for new concepts in a 3.+ branch.
Moreover we may be able to pull the older branch to an equivalent state as will be the newer one, but maybe on a more monolithic form (that also has its advantage if for instance it saves the user the pain of additional lines of code, because I suppose that the idea here is to have to add as many declarations of namespaces as used effectively in the code - but this approach adds no such comfort that the all-is-here-in-one basically brings).

But I can be misunderstanding this all. I'm not an advanced user or anything approaching. Just giving my opinion right as I understand the things are going here.

And if the oldest branch proves useless rather than a life saver -> deprecate ...

[Lost Zergling]

Python 2.7 Lists Depend on an Oracle Engine. Until then the community of developers was not bothered by the license and this partly explains the reasons for the maintenance of version 2.7 which is very powerful because originaly created with the professional technical means of a large company, even thought it was a "small" engine. I do not have an opinion about the namespace project, I'd like to point out the importance to maintain performances, perhaps this is a bit close to Tourist Trap's opinion. Some piece of best codes is usually "tidy, tiny, very core" but so hard to conceptualize (and so to code), and this seems to be antinomic with the concern about a legible build process. Coding style also an issue. If we were a prof. company, I think we perhaps would have a legible model for developping concepts on one hand, and an optimized version on other hand : the optimized version would be for the very technical aspects and may vary drastically but should serve the guidelines of the conceptual mock-up in the long run. Arbitrations between concepts and technic also an issue. So far, I'm afraid this post not a big help,... :-(