Namespaces c++/PB

[Keith Waters]

While converting some C++ I came across namespaces. I looked it up on Wikipedi and saw this quote.

“Therefore, namespaces have been added to most modern languages”

You know what I’m going to say – when will PB have namespaces?

Keith


------------------

[Eric Pearson]

Keith --

It already does. As I understand it, in this context a namespace is a "container" in which there can be no duplication of variable names. (That's what you mean, right?)

A procedure (SUB or FUNCTION) isn't allowed to have two procedure-level (local or static) variables with the same name. A module (EXE or DLL) is not allowed to have two module-level (global) variables with the same name. A MACRO is allowed to have its own namespace too, for macro-level variables.

You can implement your own namespaces by adding prefixes to your variable names, like NS1_MyVar. The NS1_ prefix would be the namespace.

Maybe I'm not grasping what you mean. Can you be more specific about what you'd like the compiler to do differently, and what benefit it would provide?

-- Eric

P.S. Keep in mind that Wikipedia is a "user generated" reference site. Anybody can post there, so it's not exactly authoritative. That's not to say that namespaces aren't common, but you have to take a statement like that with a grain of salt.

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>



[This message has been edited by Eric Pearson (edited April 14, 2005).]

[Keith Waters]

namespace is a "container" in which there can be no duplication of variable names

No – that’s not what I mean. I mean as it’s defined in http://en.wikipedia.org/wiki/Namespa...rogramming%29.

You can, and I do all the time, add prefixes to your variable names (as you and the article mention) but I would like a formal way of doing that built into PB. Inside the namespace you use names without a prefix; outside the namespace the prefix must be used.

Keith


------------------

[Eric Pearson]

Thanks for clarifying. So if I understand that article, you would start a namespace by using something like:

NAMESPACE XYZ

...and after that point in the code, the compiler would not allow you to use variables unless they began with the prefix XYZ:, as in XYZ:MyVar. The colon can't be used in BASIC because it already has a specific meaning, so I guess PB could use XYZ_MyVar or some other token like the tilde (~). The same as what I was suggesting, but enforced by the compiler.

The compiler could also support:

USING XYZ_

...and after that the compiler would automatically (and invisibly) add XYZ_ to all variables, to make typing easier.

That's interesting. It would effectively allow you to "isolate" a block of code so that the only interaction it could have with other parts of the program would be procedure calls. It would allow you, for example, to bring in an #INCLUDE file without having to worry about global naming conflicts. It would also allow you to create "regional" variables, like globals but only visible within a certain physical block of the program.

Sounds useful to me.

-- Eric


------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[Keith Waters]

Yes Eric – you have it exactly. A sample code might look like this.

NAMESPACE XYZ
  GLOBAL ii AS LONG
 
  FUNCTION Foo () AS LONG
    ...
  END FUNCTION
 
  SUB Boo ()
    LOCAL i AS LONG
    ...
    i = Foo()
    ...
  END SUB
 
END NAMESPACE
 
 
SUB OutSide ()
  LOCAL ii AS LONG,_
        ij AS LONG
 
  ii = XYZ_ii
 
  ij = XYZ_Foo()
 
END SUB

Actually what I would really like is a MODULE … END MODULE construct. Everything inside the MODULE is hidden from the “outside world” unless it’s declared to be “exported” or “public”. In other words, the MODULE should behave exactly as a linked dll.

I find there are many situations where I would like to encapsulate data and associated functions in the same manner as a dll but where a separate dll would be overkill and where the generality of the encapsulated code/data doesn’t really warrant a dll.

Currently I use name prefixes to achieve a (weak) encapsulation. Formal namespaces would be better. MODULEs would be even better.

Keith


------------------

[Eric Pearson]

The word "module" already has a specific meaning in Win32 programming.

REGION? ISOLATE?

-- Eric

[Keith Waters]

I refer to MODULEs as they are implemented in http://en.wikipedia.org/wiki/Modula-2 (played with Modula2 some while back – lovely “clean” language). MODULE’s provide proper encapsulation (which might go some way to making the OOP enthusiasts happy).

Anyway, failing MODULEs in PB, can I request that my tick be put next to namespaces for the PB compiler?

Keith


------------------

[David Roberts]

Something along the lines here or am I misunderstanding you guys?

Added: Forget that, you're obviously into this which is new to me.

------------------
David Roberts



[This message has been edited by David Roberts (edited April 14, 2005).]

[Donald Darden]

Reading up on ORGE (www.orge3d.org), it was mentioned that he was
using NameSpaces, which all modern C++ compilers should support.
But his example used a double colon (module::named_item), and it
occurred to me that it that were true, you couldused a simple
search and replace to convert double colons to double (__). Now
why wouldn't that work? Of course I don't know if there are
issues with the scope of a variable, maybe thay all have to be
declared Global for this to work, or maybe we ought to be
thinking about making these members of a type structure.

------------------
Old Navy Chief, Systems Engineer, Systems Analyst, now semi-retired

[Keith Waters]

David – yes, “this” rather than “here”.

Donald – I don’t know what you are talking about.

Keith


------------------

[Michael Mattias]

Poor Man's Namespace:

 LOCAL x&

[Stan Durham]

This is something I’ve been asking for.

I’d like to go one step further.

#NAMESPECE "TextBox1_"
'everything in the INC file gets 'TextBox1_' added in the eyes of the compiler
#INCLUDE "MyTextBoxLib.inc"
#ENDNAMESPECE

#NAMESPECE "TextBox2_"
#INCLUDE "MyTextBoxLib.inc"
#ENDNAMESPECE

also
#NAMESPECE OFF
#NAMESPECE ON

This would give you the ability to put data structures and procedures together - hidden behind a namespace - and use several different instances of the library.

In order for it to work - I think you would have to have a multi-pass compiler so you wouldn’t have to worry about what order everything gets declared.


------------------

[Michael Mattias]

#NAMESPECE "TextBox1_"
'everything in the INC file gets 'TextBox1_' added in the eyes of the compiler
#INCLUDE "MyTextBoxLib.inc"
#ENDNAMESPECE

#NAMESPECE "TextBox2_"
#INCLUDE "MyTextBoxLib.inc"
#ENDNAMESPECE

Sounds like COBOL's "COPY REPLACING."

Maybe you could do something like this with a MACRO. I'm not really very good with MACROs but maybe something like

MACRO My_TextBoxLib = Textbox_1
#INCLUDE "MyTextBoxLib.inc"
MACRO TextBox_1 = TextBox_2
#INCLUDE  "myTextboxlib.inc"  ' << in here, you'd get double MACRO substitution

[Keith Waters]

Stan – I’m not too sure about that. I get your idea about loading multi-instances of an include file. That’s a nice idea but surely that can be done with an “ordinary” NAMESPACE. In fact, you have just provided another damn good reason for having namespaces in the PB compilers. I don’t see any real need for a metacommand namespace in addition to the ordinary. As for #NAMESPACE OFF/ON, what does that do that can’t be done with USING as Eric mentioned.

Keith

------------------

[Keith Waters]

Michael – err, that doesn’t work, does it, because MACRO substitution does not work for parts of a name, only for whole names. I must be missing soething.

Keith


------------------

[Eric Pearson]

Keith --

> what does that do that can’t be done with USING as Eric mentioned.

I think you misread my post. I was suggesting that USING would be a good addition to a namespace implementation.

-- Eric

[This message has been edited by Eric Pearson (edited April 15, 2005).]

[Guest]

Why reinvent the atom, just use namespace exactly as c++ compilers do.
There should be no need to complicate it, eh?

[Michael Mattias]

Why even bother with copying he same "library" #INCLUDE file twice?

If the functions were written correctly (no GLOBAL or STATIC) (and virtually no literals) you could use the same procedures with any dialog in a totally re-entrant fashion.

Then again, I may just be whistling "Dixie" (without apology, thank you), since the #INCLUDE'd file in which the proposed substitution to me made is not shown.

[Stan Durham]

The best solution would be a genuine Module.
Variables and Procedures local to the module or exposed outside - like DLL.
I wouldn't worry about namespace if I had modules.

Whish List:
1 Modules.
2 Multi-Pass Compiler.
all equates, globals and declares moved to the top of the code before compiling.
modules won't work without a multi-pass compiler.

I have my own work-around on all of this using
Macros, Globals and gBig_Long_Ugly_Variables
It's very contrived - but I don't have time to worry about it.

MM > Why even bother with copying he same "library" #INCLUDE file twice?
encapsulate data with procedures.
they would be global or static, only hid behind a different namespace.
that does violate what some consider good practice.


------------------

[Keith Waters]

I think you misread my post.

I think you misread my post, Eric. I’m in complete agreement about having USING – sorry if I didn’t make that explicit. It’s part of the C++ implementation and is a good addition.

Why reinvent the atom, just use namespace exactly as c++ compilers do.

Agree 100%.

The best solution would be a genuine Module.

Exactly what I was saying earlier – 100% agree.

There is so much agreement here I’m beginning to get nervous.
Keith


------------------