Announcement

Collapse
No announcement yet.

Namespaces c++/PB

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Namespaces c++/PB

    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


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

  • #2
    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).]
    "Not my circus, not my monkeys."

    Comment


    • #3
      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


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

      Comment


      • #4
        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>
        "Not my circus, not my monkeys."

        Comment


        • #5
          Yes Eric – you have it exactly. A sample code might look like this.
          Code:
          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


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

          Comment


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

            REGION? ISOLATE?

            -- Eric
            "Not my circus, not my monkeys."

            Comment


            • #7
              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


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

              Comment


              • #8
                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).]

                Comment


                • #9
                  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

                  Comment


                  • #10
                    David – yes, “this” rather than “here”.

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

                    Keith


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

                    Comment


                    • #11
                      Poor Man's Namespace:
                      Code:
                       LOCAL x&
                      Michael Mattias
                      Tal Systems (retired)
                      Port Washington WI USA
                      [email protected]
                      http://www.talsystems.com

                      Comment


                      • #12
                        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.


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

                        Comment


                        • #13
                          Code:
                          #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
                          Code:
                          MACRO My_TextBoxLib = Textbox_1
                          #INCLUDE "MyTextBoxLib.inc"
                          MACRO TextBox_1 = TextBox_2
                          #INCLUDE  "myTextboxlib.inc"  ' << in here, you'd get double MACRO substitution

                          Michael Mattias
                          Tal Systems (retired)
                          Port Washington WI USA
                          [email protected]
                          http://www.talsystems.com

                          Comment


                          • #14
                            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

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

                            Comment


                            • #15
                              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


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

                              Comment


                              • #16
                                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).]
                                "Not my circus, not my monkeys."

                                Comment


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

                                  Comment


                                  • #18
                                    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.

                                    Michael Mattias
                                    Tal Systems (retired)
                                    Port Washington WI USA
                                    [email protected]
                                    http://www.talsystems.com

                                    Comment


                                    • #19
                                      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.


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

                                      Comment


                                      • #20
                                        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


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

                                        Comment

                                        Working...
                                        X