Chris Cason wrote:

> [Chris B]
> 
>>>For example, using #local in include files wherever you don't need to expose
>>>them externally.
> 
> 
> Overall I am strongly in favor of some system whereby the only things exposed
> from a specialized object or macro include file are those things the author
> intends to expose, that is, by explicit declaration. C++ uses namespaces,
> perl uses modules, other languages have their own ways; whatever, the point
> is intelligent management of exposed symbols.
> 
> [nemesis]
> 
>>i just wish #local would also be local to macros.  oh well...
> 
> 
> Recall I mentioned changes to SDL are possible. Not necessarily the above,
> perhaps, but something that gives us the same effect. Basically if enough of
> you think it's needed, tell me and we'll give it some thought. Some things
> might not be possible with the current parser but we'll at least consider it.

Keeping it simple is a must.

Namespaces are probably the best way.  Ideas:

* #namespace LABEL creates the namespace LABEL if it doesn't already 
exist.  Whether new or not, namespace LABEL becomes the active namespace 
(the former namespace is saved on a stack).

* #namespace undef pops the current namespace off of the stack, and the 
former namespace becomes active.

* All #declare and #local statements affect the variable in the current 
namespace.  Other variables of the same name in other namespaces are not 
affected.

* #declared variables live from one invocation of the namespace to the 
next, but #labeled variables die when the namespace passes out of scope 
(end of macro, end of file, popped by #namepsace undef statement).

* The arguments of a macro are, within a macro, always in scope, 
regardless of the active namespace.

This way if I write a set of macros for simulating physics (called the 
Phony Physics Pholio), I can put

   #namespace Phony_Physics_Pholio

at the start of every macro, and thereby minimize conflicts with other 
macros sets by other authors.

Regards,
John

Post a reply to this message