Next topic

[polygone]

In response to a suggestion that Josh has been throwing around for a while I would like to start a topic about this so it can be further discussed. I for one would like to see it happen.

These are some previous quotes from the Christmas plan topic about it:

Also, who among you is interested in the idea of encapsulating EDL types and functions in their own namespace? It would make it easier to deal with noise from library implementations, but it would require putting lots of shit into that namespace and using lots of shit from STDC.

In other words, we'd no longer have problems with time or list being illegal variable names unless the user specifically said, [snip=EDL]using std::list;[/snip] or [snip=EDL]using namespace std;[/snip], which I intend to unify between all viable backends (meaning, in JavaScript as well).

The new parser is much, much more adept at making these distinctions, so I can probably get it to allow using types and shit as variable names (especially in compatibility mode), but this would be a fix-all.

Encapsulation of EDL types and functions would be nice, especially if it solves the problems with "time" and "list" being used as variable names. How easy would it be to set up the system such that EDL types and functions can reside in both the global namespace and the EDL namespace? If it is easy, I would like the system to be set up that way, since that should enable easy step-wise migration.

Simple as placing "using namespace <name here>;" in the global scope. Just like you would any other namespace. I'll set ENIGMA up to read from :: or ::edlwhatever based on a macro. After everything's migrated, or we think everything's migrated, you'll just flip that flag and try compiling.

[Josh @ Dreamland]

You don't need to wait for me or the new parser to do this. Just start moving shit into [snip]namespace enigma_user[/snip], or whatever, and then use that namespace from the global scope.

It's actually not difficult to make JDI only read a certain namespace, but I'd rather it wait until the new compiler is out just because we'll have to do it twice, and I don't feel like dealing with merge conflicts when I pour master back into enigma-jdi.

[forthevin]

Good point about not waiting. In regards to the namespace name, I think Josh's suggestion of "enigma_user" sounds good.

[polygone]

Sounds fine it me, I might have gone for enigma_local but it doesn't really matter what it's called :F

[polygone]

Is this then on your todo list forthevin? Just so I know.

[forthevin]

Yes, it is on my todo list.

[polygone]

I just realized this is going to be a bitch to do with all the continuous commits, I think it needs to be planned properly.

[Goombert]

When a proper implementation is layed out and more explicit instructions given I will begin to tackle this. 

[polygone]

It would be a good time to do it since there are few commits right now.

[forthevin]

I have moved some of the user functions and variables into the enigma_user namespace. I will move more later, but I will stay outside of collisions and graphics, to avoid moving things others are moving.

[polygone]

I have moved some of the user functions and variables into the enigma_user namespace. I will move more later, but I will stay outside of collisions and graphics, to avoid moving things others are moving.

It's alright nobody is working on any collision or graphics functions right now, I don't think. Now's the best time to move everything, and all at once.

[polygone]

Ok I see you've just committed. The problem is those functions aren't going to be available now to people using ENIGMA. This is why it's best to do the whole wrong at once, or at least quickly. Maybe it would be a better idea to branch off actually.

[forthevin]

No, they are actually available, I tested it myself. The solution is that I put:

Code Select Expand


namespace enigma_user {};

using namespace enigma_user;


in SHELLmain.cpp, such that the namespace is available to the users, like Josh instructed. That way, user variables/functions that reside in either the global or enigma_user namespace are available to the user.

[Josh @ Dreamland]

The only thing you should watch out for is some of the existing hacks. Most of them are local to the math header. I define the bessel functions to be declared with a bessel_ prefix to avoid conflicts with variable names like y1. There are other, similar hacks. Removing those will break some games. When the move is finished, the macros that do that will need to be removed, and the bessel functions simply declared in namespace enigma_user to call the corresponding stdc functions in ::.

Make sure, also, that somewhere in the code, [snip=cpp]namespace enigma_user { using ::var; using ::variant; }[/snip] appears.

When you guys are ready, tell me, and I'll make the very few changes necessary to change from :: to ::enigma_user.

[polygone]

No, they are actually available, I tested it myself. The solution is that I put:

Code Select Expand


namespace enigma_user {};

using namespace enigma_user;


in SHELLmain.cpp, such that the namespace is available to the users, like Josh instructed. That way, user variables/functions that reside in either the global or enigma_user namespace are available to the user.

Shouldn't you commit that then?