PureBasic Forums - English

Posted: **Sat Sep 07, 2013 11:21 am**

Hi,

in earlier 5.20 beta versions there were several bugs in the implementation of the new module feature, which have been found bit by bit in the course of time. The current version beta 17 still contains module bugs (see below), and I feel that it would be useful if these things were tested more systematically.

So I've written some basic test code snippets for modules. Test #3 shows two bugs that are still present in beta 17. Code snippets like these can also help people ( including myself

) to understand how exactly modules are supposed to work.

Of course the following snippets do not cover the whole topic and can't fetch all possible bugs in this field. But they are a beginning, and I think it would be helpful if other people would post additional test code snippets for modules in this thread.

//edit 2013-09-23:

Cosmetic changes in tests #1, #2, and #3
Added test #4 (based on bug reports by idle and luis, using PB 5.20 beta 17)

Tested all 4 code snippets with PB 5.20 final => everything works as expected.

Module test #1

Code: Select all

; PB 5.20 LTS final
; => Uncommenting any of the commented lines will raise an error.
;
; Conclusions:
; - Variables that are declared in the main scope of the program
;   (i.e. outside of a module) can not be accessed in a module.
; - Variables that are declared in the main scope of a program
;   can of course be accessed in the main scope. As usual, if
;   they are declared outside of a procedure (i.e. not Protected),
;   they can be accessed in a procedure only if they are Global
;   (or Shared; not tested here).

Define a.i = 1
Dim b.i(1) : b(0) = 2
NewMap c.i() : c("foo") = 3
NewList d.i() : AddElement(d()) : d() = 4

Global e.i = 5
Global Dim f.i(1) : f(0) = 6
Global NewMap g.i() : g("foo") = 7
Global NewList h.i() : AddElement(h()) : h() = 8


DeclareModule MyModule
   EnableExplicit

   ; Debug a
   ; Debug b(0)
   ; Debug c()
   ; Debug d()

   ; Debug e
   ; Debug f(0)
   ; Debug g()
   ; Debug h()
EndDeclareModule

Module MyModule
   Procedure ModuleProc()
      ; Debug a
      ; Debug b(0)
      ; Debug c()
      ; Debug d()

      ; Debug e
      ; Debug f(0)
      ; Debug g()
      ; Debug h()
   EndProcedure

   ModuleProc()

   ; Debug a
   ; Debug b(0)
   ; Debug c()
   ; Debug d()

   ; Debug e
   ; Debug f(0)
   ; Debug g()
   ; Debug h()
EndModule


EnableExplicit

Procedure MainProc()
   ; Debug a
   ; Debug b(0)
   ; Debug c()
   ; Debug d()

   Debug e       ; writes 5, OK
   Debug f(0)    ; writes 6, OK
   Debug g()     ; writes 7, OK
   Debug h()     ; writes 8, OK
   Debug "---"
EndProcedure

MainProc()

Debug a          ; writes 1, OK
Debug b(0)       ; writes 2, OK
Debug c()        ; writes 3, OK
Debug d()        ; writes 4, OK

Debug e          ; writes 5, OK
Debug f(0)       ; writes 6, OK
Debug g()        ; writes 7, OK
Debug h()        ; writes 8, OK

Module test #2

Code: Select all

; PB 5.20 LTS final
; => Uncommenting any of the commented lines will raise an error.
;
; Conclusions:
; - Variables that are declared in the 'Module' part can neither
;   be accessed in the 'DeclareModule' part nor in the main scope
;   of the program.
; - Variables that are declared in the 'Module' part can of
;   course be accessed inside this part. As usual, if they
;   are declared outside of a procedure (i.e. not Protected),
;   they can be accessed in a procedure only if they are Global
;   (or Shared; not tested here).

DeclareModule MyModule
   EnableExplicit

   ; Debug a
   ; Debug b(0)
   ; Debug c()
   ; Debug d()

   ; Debug e
   ; Debug f(0)
   ; Debug g()
   ; Debug h()
EndDeclareModule

Module MyModule
   Define a.i = 1
   Dim b.i(1) : b(0) = 2
   NewMap c.i() : c("foo") = 3
   NewList d.i() : AddElement(d()) : d() = 4

   Global e.i = 5
   Global Dim f.i(1) : f(0) = 6
   Global NewMap g.i() : g("foo") = 7
   Global NewList h.i() : AddElement(h()) : h() = 8

   Procedure ModuleProc()
      ; Debug a
      ; Debug b(0)
      ; Debug c()
      ; Debug d()

      Debug e       ; writes 5, OK
      Debug f(0)    ; writes 6, OK
      Debug g()     ; writes 7, OK
      Debug h()     ; writes 8, OK
      Debug "---"
   EndProcedure

   ModuleProc()

   Debug a          ; writes 1, OK
   Debug b(0)       ; writes 2, OK
   Debug c()        ; writes 3, OK
   Debug d()        ; writes 4, OK

   Debug e          ; writes 5, OK
   Debug f(0)       ; writes 6, OK
   Debug g()        ; writes 7, OK
   Debug h()        ; writes 8, OK
EndModule


EnableExplicit

Procedure MainProc()
   ; Debug a
   ; Debug b(0)
   ; Debug c()
   ; Debug d()

   ; Debug e
   ; Debug f(0)
   ; Debug g()
   ; Debug h()
EndProcedure

MainProc()

; Debug a
; Debug b(0)
; Debug c()
; Debug d()

; Debug e
; Debug f(0)
; Debug g()
; Debug h()

; Debug MyModule::a
; Debug MyModule::b(0)
; Debug MyModule::c()
; Debug MyModule::d()

; Debug MyModule::e
; Debug MyModule::f(0)
; Debug MyModule::g()
; Debug MyModule::h()

UseModule MyModule
; Debug a
; Debug b(0)
; Debug c()
; Debug d()

; Debug e
; Debug f(0)
; Debug g()
; Debug h()

Module test #3

Code: Select all

; PB 5.20 LTS final
; => Uncommenting any of the commented lines will raise an error.
;
; Conclusions:
; - Variables that are declared in the 'DeclarModule' part can
;   be accessed in both parts of the module and in the main scope
;   of the program.
; - The variable scope *inside* the module is determined by
;   keywords such as Define, Global etc.
; - The variable scope *outside* the module is *not* determined by
;   these keywords. Public module variables can be accessed
;   *everywhere* outside the module by using either "ModuleName::..."
;   or "UseModule ...".

DeclareModule MyModule
   EnableExplicit

   Define a.i = 1
   Dim b.i(1) : b(0) = 2
   NewMap c.i() : c("foo") = 3
   NewList d.i() : AddElement(d()) : d() = 4

   Global e.i = 5
   Global Dim f.i(1) : f(0) = 6
   Global NewMap g.i() : g("foo") = 7
   Global NewList h.i() : AddElement(h()) : h() = 8

   Debug a               ; writes 1, OK
   Debug b(0)            ; writes 2, OK
   Debug c()             ; writes 3, OK
   Debug d()             ; writes 4, OK

   Debug e               ; writes 5, OK
   Debug f(0)            ; writes 6, OK
   Debug g()             ; writes 7, OK
   Debug h()             ; writes 8, OK
   Debug "---"
EndDeclareModule

Module MyModule
   Procedure ModuleProc()
      ; Debug a
      ; Debug b(0)
      ; Debug c()
      ; Debug d()

      Debug e            ; writes 5, OK
      Debug f(0)         ; writes 6, OK
      Debug g()          ; writes 7, OK
      Debug h()          ; writes 8, OK
      Debug "---"
   EndProcedure

   ModuleProc()

   Debug a               ; writes 1, OK
   Debug b(0)            ; writes 2, OK
   Debug c()             ; writes 3, OK
   Debug d()             ; writes 4, OK

   Debug e               ; writes 5, OK
   Debug f(0)            ; writes 6, OK
   Debug g()             ; writes 7, OK
   Debug h()             ; writes 8, OK
   Debug "==="
EndModule


EnableExplicit

Procedure MainProc()
   Debug MyModule::a     ; writes 1, OK
   Debug MyModule::b(0)  ; writes 2, OK
   Debug MyModule::c()   ; writes 3, OK
   Debug MyModule::d()   ; writes 4, OK

   Debug MyModule::e     ; writes 5, OK
   Debug MyModule::f(0)  ; writes 6, OK
   Debug MyModule::g()   ; writes 7, OK
   Debug MyModule::h()   ; writes 8, OK
   Debug "---"

   UseModule MyModule
   Debug a               ; writes 1, OK
   Debug b(0)            ; writes 2, OK
   Debug c()             ; writes 3, OK
   Debug d()             ; writes 4, OK

   Debug e               ; writes 5, OK
   Debug f(0)            ; writes 6, OK
   Debug g()             ; writes 7, OK
   Debug h()             ; writes 8, OK
   Debug "---"
   UnuseModule MyModule
EndProcedure

MainProc()

; Debug a
; Debug b(0)
; Debug c()
; Debug d()

; Debug e
; Debug f(0)
; Debug g()
; Debug h()

Debug MyModule::a        ; writes 1, OK
Debug MyModule::b(0)     ; writes 2, OK
Debug MyModule::c()      ; writes 3, OK
Debug MyModule::d()      ; writes 4, OK

Debug MyModule::e        ; writes 5, OK
Debug MyModule::f(0)     ; writes 6, OK
Debug MyModule::g()      ; writes 7, OK
Debug MyModule::h()      ; writes 8, OK
Debug "---"

UseModule MyModule
Debug a                  ; writes 1, OK
Debug b(0)               ; writes 2, OK
Debug c()                ; writes 3, OK
Debug d()                ; writes 4, OK

Debug e                  ; writes 5, OK
Debug f(0)               ; writes 6, OK
Debug g()                ; writes 7, OK
Debug h()                ; writes 8, OK

Module test #4

Code: Select all

; PB 5.20 LTS final

; Conclusions:
; - Inside procedures in a module, 'Protected' variables have
;   a higher priority than 'Global' variables.
; - Inside procedures in the main scope, 'Protected' variables
;   have a higher priority than public module variables.

DeclareModule MyModule
   EnableExplicit

   Define a.i = 1
   Dim b.i(1) : b(0) = 2
   NewMap c.i() : c("foo") = 3
   NewList d.i() : AddElement(d()) : d() = 4

   Global e.i = 5
   Global Dim f.i(1) : f(0) = 6
   Global NewMap g.i() : g("foo") = 7
   Global NewList h.i() : AddElement(h()) : h() = 8
EndDeclareModule

Module MyModule
   Procedure ModuleProc()
      Protected a.i
      Protected Dim b.i(1)
      Protected NewMap c.i() : AddMapElement(c(), "foo")
      Protected NewList d.i() : AddElement(d())

      Protected e.i
      Protected Dim f.i(1)
      Protected NewMap g.i() : AddMapElement(g(), "foo")
      Protected NewList h.i() : AddElement(h())

      Debug a       ; writes 0, OK
      Debug b(0)    ; writes 0, OK
      Debug c()     ; writes 0, OK
      Debug d()     ; writes 0, OK

      Debug e       ; writes 0, OK
      Debug f(0)    ; writes 0, OK
      Debug g()     ; writes 0, OK
      Debug h()     ; writes 0, OK
      Debug "---"
   EndProcedure

   ModuleProc()

   Debug a          ; writes 1, OK
   Debug b(0)       ; writes 2, OK
   Debug c()        ; writes 3, OK
   Debug d()        ; writes 4, OK

   Debug e          ; writes 5, OK
   Debug f(0)       ; writes 6, OK
   Debug g()        ; writes 7, OK
   Debug h()        ; writes 8, OK
   Debug "==="
EndModule


EnableExplicit
UseModule MyModule

Procedure MainProc1()
   Protected a.i
   Protected Dim b.i(1)
   Protected NewMap c.i() : AddMapElement(c(), "foo")
   Protected NewList d.i() : AddElement(d())

   Protected e.i
   Protected Dim f.i(1)
   Protected NewMap g.i() : AddMapElement(g(), "foo")
   Protected NewList h.i() : AddElement(h())

   Debug a          ; writes 0, OK
   Debug b(0)       ; writes 0, OK
   Debug c()        ; writes 0, OK
   Debug d()        ; writes 0, OK

   Debug e          ; writes 0, OK
   Debug f(0)       ; writes 0, OK
   Debug g()        ; writes 0, OK
   Debug h()        ; writes 0, OK
   Debug "---"
EndProcedure

Procedure MainProc2()
   Protected a.i = 9
   Protected Dim b.i(1) : b(0) = 10
   Protected NewMap c.i() :  : c("foo") = 11
   Protected NewList d.i() : AddElement(d()) : d() = 12

   Protected e.i = 13
   Protected Dim f.i(1) : f(0) = 14
   Protected NewMap g.i() : g("foo") = 15
   Protected NewList h.i() : AddElement(h()) : h() = 16

   Debug a          ; writes  9, OK
   Debug b(0)       ; writes 10, OK
   Debug c()        ; writes 11, OK
   Debug d()        ; writes 12, OK

   Debug e          ; writes 13, OK
   Debug f(0)       ; writes 14, OK
   Debug g()        ; writes 15, OK
   Debug h()        ; writes 16, OK
   Debug "---"
EndProcedure

MainProc1()
MainProc2()

Debug a             ; writes 1, OK
Debug b(0)          ; writes 2, OK
Debug c()           ; writes 3, OK
Debug d()           ; writes 4, OK

Debug e             ; writes 5, OK
Debug f(0)          ; writes 6, OK
Debug g()           ; writes 7, OK
Debug h()           ; writes 8, OK

Posted: **Sat Sep 07, 2013 12:20 pm**

Hi Little John,

Thank you for all the time and trouble you have taken in preparing these test programs.
I'm finding them educational.

Posted: **Sat Sep 07, 2013 3:32 pm**

Hi davido,

you are welcome.
Thanks for your feedback!

Posted: **Sat Sep 07, 2013 4:58 pm**

I think it's a nice idea, I'll give them a whirl.
Unfortunately for me I thought I had understood the modules as implemented in PB but the last bug reports put my convictions in jeopardy.
I admit I have a pretty nice confusion in my head now.

Maybe the fog will go away after some more use.

I tried them, nice, thank you.
The part that bothers me is this:

Code: Select all

; - The variable scope *outside* the module is *not* determined by
;   these keywords. The variables can be accessed *everywhere*
;   outside the module where they have been defined by using either
;   "ModuleName::..." or "UseModule ...".

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

UseModule x

Debug y ; I understand this

Procedure foo()
 Debug y ; but I don't understand why this should work, I don't see the logic behind this
EndProcedure

foo()

Let's confine us to UseModule and forget about "::" for simplicity.
My idea about modules was:
What is in the DeclareModule section is the interface to the module. It is the part the module want to show about itself.
What is in the Module section is the private core of the module.
What I do with UsingModule is to "open up" the module, to copy/paste its interface part inside my current scope.

The functions declared become accessible, I can call them.
Same with constants, I can use them.
The variables are "pasted" in my current scope. So a Global is still a global, a Define is still a define.

In my example above, I would expect "y" to be "pasted" in my current scope: the main one in the code above.
So I would expect to access "y" from the main scope but NOT from inside the procedure, where the scope changes to a new one.

If someone can explain to me why it is a good idea to ignore the original scope of the objects instead of keep it by simply doing no more then opening up the envelope containing the module (virtually removing the DeclareModule/EndModule pair to let its content out) I would appreciate it.

The only "logic" I could see is:
since using modname::item I can access everything specified in the DeclareModule section (simply because I can specify a path to it) let's say everything is treated the same and forget about any pesky scope specifier attached.
If we accept that then we can somewhat justify why it happens with UseModule too.
That's the best I could come with, but if I look at my code example above I don't like it anyway.

Posted: **Sat Sep 07, 2013 9:06 pm**

luis wrote:If someone can explain to me why it is a good idea to ignore the original scope of the objects instead of keep it by simply doing no more then opening up the envelope containing the module (virtually removing the DeclareModule/EndModule pair to let its content out) I would appreciate it.

That's what puzzles me too. I can only assume that people who wish to do this don't understand what modules are. Unfortunately, novice programmers won't realize that blithely ignoring the module interface will create bugridden spaghetti code.

As I said when the Module feature was first announced, there's no need for a UseModule feature. But if people want to write unmaintainable code, it's their choice. I'm not going to lose any sleep over it.

The whole Module feature seems to have not been well thought out. And the lack of really good documentation doesn't help.

Posted: **Sat Sep 07, 2013 11:45 pm**

Code: Select all

DeclareModule x
 Define y = 33
EndDeclareModule

creates a global x.v_y

Code: Select all

UseModule x

resolve scope of x

Code: Select all

Debug y

resolves x.v_y

Code: Select all

Procedure foo()
 Debug y ; there is no private y so resolves x.v_y 
EndProcedure

There is no private y so it resolves x.v_y

Code: Select all

Procedure foo()
 Protected y 
 Debug y ;  bug here  
EndProcedure

I think this is a bug, local scope should take precedence over global scope regardless
of whether use module is called

Posted: **Sun Sep 08, 2013 12:01 am**

@idle

Thanks for trying. That's what happen but does not explain why.
I still don't see the logic behind the reason why "y" should be accessible inside the proc.
All start from the assumption is ok to discard the scope specifier from the vars inside DeclareModule and make them global.
If I agree with that, all follows. But I don't understand why it should be a good idea. A better idea than not doing so.
Why it has been implemented this way ? If I get a good answer probably I can avoid to simply memorize it blindly as rule and understand it instead. It would be a lot better.

luis wrote: ... why it is a good idea to ignore the original scope of the objects instead of keep it by simply doing no more then opening up the envelope containing the module (virtually removing the DeclareModule/EndModule pair to let its content out) ...

About this:

Code: Select all

Procedure foo()
 Protected y 
 Debug y ;  bug here  
EndProcedure

idle wrote: I think this is a bug, local scope should take precedence over global scope regardless
of whether use module is called

Good {insert divinity name here} I also hope this is bug !

Interestingly if you change it to

Code: Select all

 Protected y = 5

It access the local one. {EDIT: actually no, I just noticed it overwrites the module's variable, looked only that way}

Brrrrr.rrr..rrr......

Ok, it's a bug.

Posted: **Sun Sep 08, 2013 12:49 am**

I don't see an issue with the module variable being resolved in an external procedure
when it doesn't have a protected variable the behaviour is consistent with the current scope resolution protected global
the fact that you told the compiler to resolve for the modules variables, I'd expect it to behave as

protected -> module -> global

but it doesn't really do that

Here's another bug

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

Global y = 20   ; var is "v_y"  Scope resolution: - > global 

UseModule x   ;Errors here with module public variable "y" is already decalred in global scope ?  
  Debug y ; var is  "x.v_y"  Scope resolution:  module -> global 
UnuseModule x 

Debug y   

UseModule x 
 Procedure foo()
   Protected y   ; if protected y isn't assigned debugs x.v_y  
   Debug y ;  Scope resolution should be : protected -> module -> global 
 EndProcedure
 
 foo()

Posted: **Sun Sep 08, 2013 4:25 am**

I don't think I've seen a new feature generate as many bugs in a beta as Module support has.
Compiler issues, IDE issues, etc.
Poor Fred, he probably has a few more grey hairs ... but not as many as me yet!

Makes me wonder, is this going to be a continuous long-term reliability headache as PB moves forward? Is it worth it?

Posted: **Sun Sep 08, 2013 4:44 am**

idle wrote:Here's another bug

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

Global y = 20   ; var is "v_y"  Scope resolution: - > global 

UseModule x   ;Errors here with module public variable "y" is already decalred in global scope ?  
  Debug y ; var is  "x.v_y"  Scope resolution:  module -> global 
UnuseModule x 

Debug y   

UseModule x 
 Procedure foo()
   Protected y   ; if protected y isn't assigned debugs x.v_y  
   Debug y ;  Scope resolution should be : protected -> module -> global 
 EndProcedure
 
 foo()

Why is it a bug?

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

Global y = 20   ; var is "v_y"  Scope resolution: - > global 

UseModule x ;Errors here with module public variable "y" is already decalred in global scope ?
  Debug y
UnuseModule x

You can't import namespace x because namespace x contains a variable y. There is already a variable y in global namespace, that's why namespace x can't be imported.
Otherwise there would be two variables y in global namespace.

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

Global y = 20   ; var is "v_y"  Scope resolution: - > global 

Debug y ; outputs 20

Procedure foo()
   Protected y
   Debug y ; outputs 0
EndProcedure
 
foo()

Works as expected here. Protected y creates a new, local variable within the procedure.

luis wrote:

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

UseModule x

Debug y ; I understand this

Procedure foo()
 Debug y ; but I don't understand why this should work, I don't see the logic behind this
EndProcedure

foo()

Yep, looks like a bug. "Debug y" in the procedure should only work if it is marked as Global in the module.

Posted: **Sun Sep 08, 2013 4:56 am**

USCode wrote:Makes me wonder, is this going to be a continuous long-term reliability headache as PB moves forward? Is it worth it?

Just get rid of UseModule and all the problems will go away. The "::" notation is all that's needed.

Here's a modified version of idle's code, eliminating the UseModule. Uncomment the protected "y" in "foo" to see how things change:

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

Global y = 20

;UseModule x  
  Debug x::y
;UnuseModule x

Debug y   

;UseModule x
Procedure foo()
;   Protected y = 99 
   Debug y 
   Debug x::y 
EndProcedure
;UnUseModule x

 foo()

Posted: **Sun Sep 08, 2013 5:01 am**

@danilo

Comment out the "Global" and "Debug y" statements in idle's example.

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

;Global y = 20   ;  <---- comment out

UseModule x   ;Errors here with module public variable "y" is already decalred in global scope ? 
  Debug y ; var is  "x.v_y"  Scope resolution:  module -> global
UnuseModule x

;Debug y   ;  <---- comment out

UseModule x
 Procedure foo()
   Protected y   ; if protected y isn't assigned debugs x.v_y 
   Debug y ;  Scope resolution should be : protected -> module -> global
 EndProcedure
 
 foo()

Posted: **Sun Sep 08, 2013 5:12 am**

BorisTheOld wrote:@danilo

Comment out the "Global" and "Debug y" statements in idle's example.

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

;Global y = 20   ;  <---- comment out

UseModule x   ;Errors here with module public variable "y" is already decalred in global scope ? 
  Debug y ; var is  "x.v_y"  Scope resolution:  module -> global
UnuseModule x

;Debug y   ;  <---- comment out

UseModule x
 Procedure foo()
   Protected y   ; if protected y isn't assigned debugs x.v_y 
   Debug y ;  Scope resolution should be : protected -> module -> global
 EndProcedure
 
 foo()

Yes, that's a bug. Probably the same bug as in luis's code (see my last posting, I changed it while you answered).

Posted: **Sun Sep 08, 2013 5:17 am**

You can't import namespace x because namespace x contains a variable y. There is already a variable y in global namespace, that's why namespace x can't be imported.
Otherwise there would be two variables y in global namespace.

No, that is clearly not the case! "x.v_y" is not the same a "v_y"
modules variables are simply prefixed with the modules name in asm

Usemodule is just a convenience in my opinion and probably should have been implemented as WithModule
even though you can explicitly resolve the scope manually it shouldn't be a problem

Posted: **Sun Sep 08, 2013 5:30 am**

idle wrote:
You can't import namespace x because namespace x contains a variable y. There is already a variable y in global namespace, that's why namespace x can't be imported.
Otherwise there would be two variables y in global namespace.
No, that is clearly not the case! "x.v_y" is not the same a "v_y"
modules variables are simply prefixed with the modules name in asm

Who speaks about ASM? We are speaking about PureBasic:
If you have a global variable y in PureBasic and you do UseModule x (which contains also a variable y),
you would end up with two variables y in global namespace!
If you use y then, PB would not know if you want to use the global y or the imported y from namespace x.
In PB you just write "y", not "x.v_y" nor "v_y".
So PB gives an error if such a conflict (two 'y') occurs:

Code: Select all

EnableExplicit

DeclareModule x
 Define y = 33
EndDeclareModule

Module x     
EndModule   

Global y

UseModule x

Debug y ; what y is meant? Global y or x::y?

idle wrote:Usemodule is just a convenience in my opinion and probably should have been implemented as WithModule
even though you can explicitly resolve the scope manually it shouldn't be a problem

UseModule and WithModule would do the same: Import a NameSpace.
Do you want that "WithModule" overwrites global scope (like a procedure scope)?
So "EndWithModule" would switch back to parent scope? Could be good idea, so just ask Fred for new feature.

Fred said it is a namespace and works exactly in that way. It has added access right: public and private.
Everything between DeclareModule/EndDeclareModule is public and be accessed from outside and can be imported with UseModule.
Everything between Module/EndModule is private and can never be accessed from outside with PB itself (not speaking about ASM level access

).

But it is no "object" or something like that. I wonder why they didn't call it namespace if it is a namespace!?
To understand the module access rights, I always have to remember it is just a namespace,
otherwise I get confused...

PureBasic Forums - English

Collection of test code snippets for modules

Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules

Re: Collection of test code snippets for modules