Modules. What are they!?

[BorisTheOld]

Why can't we have a global namespace to access?

Some compilers do have a default global namespace. And in PB notation this would allow "::GlobalItemName", which is certainly a lot easier than all that declaring.

I must confess that I'm not thrilled about the PB implementation of modules. It's too messy for my style of programming, so I don't plan to use it.

[Deluxe0321]

@TI-994A Thank you for the examples.

Anyway, currently I need to redefine these constants/procedures in every module I intent to use it. This causes trouble, for example by using a data section:

Code: Select all

;Workarround:
;DeclareModule GlobalConst
;  #XPATH = #PB_Compiler_Home + "Examples\3D\Data\"
;EndDeclareModule


DeclareModule bar
  ;current
  #XPATH = #PB_Compiler_Home + "Examples\3D\Data\"

  ; I need to define it here, won't work outside of the Module
  DataSection 
    __foobar:
    ;current
    IncludeBinary #XPATH+"PureBasic.bmp"
    ;workarround
    ;IncludeBinary GlobalConst::#XPATH+"PureBasic.bmp"
    __foobar_end:
    ;----------------------------------------
  EndDataSection
  
  Declare.i bar()
EndDeclareModule

Module bar
  
  Procedure.i bar()
    *mem = AllocateMemory(?__foobar_end - ?__foobar)
    CopyMemory(?__foobar, *mem,MemorySize(*mem))
    ProcedureReturn *mem
  EndProcedure
  
EndModule

;------- file 2 ---------

DeclareModule foo
  ;current
   #XPATH = #PB_Compiler_Home + "Examples\3D\Data\"

  ; I need to define it here, won't work outside of the Module
  DataSection 
    __barfoo:
    IncludeBinary #XPATH+"PureBasicLogo.bmp"
    ;workarround
    ;IncludeBinary GlobalConst::#XPATH+"PureBasicLogo.bmp"    
    __barfoo_end:
    ;----------------------------------------
  EndDataSection
  
  Declare.i foo()
EndDeclareModule

Module foo
  Procedure.i foo()
    *mem = AllocateMemory(?__barfoo_end - ?__barfoo)
    CopyMemory(?__barfoo, *mem, MemorySize(*mem))
    ProcedureReturn *mem
  EndProcedure
EndModule


Debug foo::foo()
Debug bar::bar()

//edit: Corrected the Code to make it runable

I know I could declare a special module just for the data section, but it still feels strange to do it like that.

Thank you!

[Fred]

It's not a workaround, it's the way to go. Just put "UseModule GlobalConst" inside your other modules and you're done. Allowing "::Item" to access global item space cleary breaks the blackbox concept of module, as it becomes dependant of your main program.

[User_Russian]

Black box is fine but do not need limit the ability of programmer (IMHO).
Access to the global scope (":: Item") not will be superfluous.

[Deluxe0321]

@Fred
I like the Black Box concept, that's not the question - that indicates and forces us to use a specific style - but I can't understand how "::Var" is breaking something.
We could have a MAIN namespace and the namespace of the diffrent modules. I think this would help to write much better code.
Anyway, thank you for the Module implementation - It's still very usefull, not for everything - but still it is.


Thank you!

[luis]

I like the Black Box concept, that's not the question - that indicates and forces us to use a specific style - but I can't understand how "::Var" is breaking something.

Clearly the nameless name space could lead to sloppy coding, and clearly is against the code isolation idea of the module, but you can abuse and do sloppy coding with all we have already available. I would prefer to have that ability and not use it.
And if I want to use it to take a shortcut or write something not clean, or to create external dependencies form my module it's up to me.

Deluxe, keep in mind the option shown here -> http://www.purebasic.fr/english/viewtop ... 00#p418000

You can use a "common" module to be shared with other modules, but you can also pass global external data, pointer to functions, etc. when you initialize your module. Another way to get access to something outside it. Not saying is beautiful, but maybe could be useful or maybe not. Just in case.

[BorisTheOld]

It's not a workaround, it's the way to go. Just put "UseModule GlobalConst" inside your other modules and you're done. Allowing "::Item" to access global item space cleary breaks the blackbox concept of module, as it becomes dependant of your main program.

Fred, that's a specious argument, since the "Module::Item" notation also breaks the blackbox concept of modules. As Luis points out, any language feature can be used to create bad code.

An unnamed global namespace can be a useful place to put global stuff, so it should be easy to get at. The "::Item" notation is a clean way to do this.

People have their own ways of coding, and if some choose to write bad code, that's their choice. However, if professional programmers think that a feature is desirable, then it might be worth implementing.

[TI-994A]

Just put "UseModule GlobalConst" inside your other modules and you're done.

Hello Fred. I understand what you mean, and it works, but I don't understand how it should be possible. When a module is used with UseModule or the double colons in the global namespace, it is possible because the module was declared in the global namespace. But how does a module, which is in a blackboxed namespace, recognise another module which has only been declared in the global namespace? Doesn't it mean that it has received/recognised the declaration from the global namespace?

Code: Select all

DeclareModule a   ;declared in the global namespace
  a = 123
EndDeclareModule

DeclareModule b
  b = a::a        ;this works although a::a has not 
EndDeclareModule  ;been declared in this namespace

Debug b::b        ;this works because a::a has been  [EDIT: not a::a but b::b]
                  ;declared in the global namespace

[Deluxe0321]

@TI-994A
Best example so far, that demonstrates my "confusion".

I personaly love Purebasic because it gives me a great possiblity to write fast and !working! prototype code without having the overhead of, let's say, Java or C#.
Fully understandable that clean and well declared code is usually the way to go - but, sometimes, you simply don't want to be the "good boy" - you want and may need to mess arround a bit .

So, what BorisTheOld wrote is probably the right thing:

People have their own ways of coding, and if some choose to write bad code, that's their choice. However, if professional programmers think that a feature is desirable, then it might be worth implementing.

Thank you!

[Fred]

Just put "UseModule GlobalConst" inside your other modules and you're done.

Hello Fred. I understand what you mean, and it works, but I don't understand how it should be possible. When a module is used with UseModule or the double colons in the global namespace, it is possible because the module was declared in the global namespace. But how does a module, which is in a blackboxed namespace, recognise another module which has only been declared in the global namespace? Doesn't it mean that it has received/recognised the declaration from the global namespace?

Code: Select all

DeclareModule a   ;declared in the global namespace
  a = 123
EndDeclareModule

DeclareModule b
  b = a::a        ;this works although a::a has not 
EndDeclareModule  ;been declared in this namespace

Debug b::b        ;this works because a::a has been  [EDIT: not a::a but b::b]
                  ;declared in the global namespace

Your code is invalid as it miss the Module:EndModule part for both modules. It has been fixed for the next beta.

[TI-994A]

Your code is invalid as it miss the Module:EndModule part for both modules. It has been fixed for the next beta.

Hello Fred, and thanks for your reply. However, I think that you've missed my point. The sample works, and with or without the Module/EndModule sections, the question was relating to the namespace.

How does module B recognise the declaration of module A? Module A has only been declared in the global namespace and not inside module B? I thought that modules, especially their public components, would only be recognised and usable if they are declared inside the namespace where they are to be used?

Code: Select all

DeclareModule A   ;module A declared in the global namespace
  x = 123
EndDeclareModule

Module A
EndModule

Debug A::x        ;module A recognised in global namespace - CORRECT

DeclareModule B   ;module A not declared in module B's namespace
  x = A::x        ;so, how is module A recognised in module B?
EndDeclareModule  

Module B
EndModule

Debug B::x        ;and it works too!

It seems to be inheriting the declaration from the global namespace, which according to you, is not allowed.

Thank you for your attention.

[Fred]

When you explicitely specify a module prefix, it does work everywhere.

[TI-994A]

We you explicitely specify a module prefix, it does work everywhere.

Alright then. Thank you.

[BorisTheOld]

@Fred

What we need is a comprehensive set of documentation for the Module feature. The problem with testing beta versions without documentation is that we cannot test new features, or even changed features, in a meaningful way.

It's obvious that a lot of people have wasted a lot of time trying to figure out how to use Modules. The same was true of the new Designer. So next time, please spend a few extra days putting together some useful documentation before releasing a beta version.

I'm getting very nervous about PB. This latest release has been very buggy and gives the impression that it was thrown together without being well thought out. I'd rather wait a year or two between releases, and know that the beta release was fairly stable, than see sloppy code released every few months for users to beta test.

[Danilo]

We can use global structures, macros, constants (that are defined in PB resident files), and global PB functions (from PB libs)
within our modules.
We are not allowed to use our own global structures, macros, constants, and functions within modules. So we have to duplicate
helper functions and macros like min(), max(), LOWORD(), HIWORD(), etc. for every module or make at least one copy into a "global module",
to use such functions within modules and outside modules as ordinary functions/macros.

Somehow I think accessing the global namespace from within modules could be useful sometimes. Maybe with "Global::", "PB::", or just anonymous "::" prefix.