Declaration of structures in the module

[User_Russian]

What should I do if the structure should be public, but the structure contains a lot of private structures that should not be accessible outside of the module?
This method does not work.

Code: Select all

DeclareModule x

  Structure Public
    var.Private
  EndStructure
  
EndDeclareModule

Module x

  Structure Private
  EndStructure
  
EndModule

You need to add the command DeclareStruct.

Code: Select all

DeclareModule x

  DeclareStruct Public
  
EndDeclareModule

Module x

  Structure Private
  EndStructure
  
  Structure Public
    var.Private
  EndStructure
  
EndModule
  
Test.x::Public

[User_Russian]

Another argument for adding DeclareStruct.

Code: Select all

DeclareModule x

  Declare Test(*y.Param)
  
EndDeclareModule

Module x

  Structure Param
    var.l
  EndStructure
  
  Procedure Test(*y.Param)
  EndProcedure
  
EndModule

[Josh]

My knowledge about modules is very slightly, but maybe Extends can help:

Code: Select all

DeclareModule x

  Structure Public
    varPublic.i
  EndStructure
  
EndDeclareModule

Module x

  Structure Private Extends Public
    varPrivate
  EndStructure

EndModule

[User_Russian]

My knowledge about modules is very slightly, but maybe Extends can help:

Is necessary that the structure of "Public", would contain the structure of "Private", and not vice versa as in your example.

[luis]

You need to add the command DeclareStruct.

The first comment which comes to mind is: MY GOD ANOTHER DECLARE

Problem is I don't think it would be enough anyway.

For example, using your proposed syntax

Code: Select all

DeclareModule x
 
  DeclareStruct Public
    
  #test = SizeOf(Public) ; the compiler has no idea
EndDeclareModule


Module x
  Structure Private
    a.i
    b.i
    c.i
  EndStructure
 
  Structure Public
    var.Private
  EndStructure
EndModule

[Little John]

What should I do if the structure should be public, but the structure contains a lot of private structures that should not be accessible outside of the module?

I do not think that that will work anyway.
How should e.g. the following suggested code work, if the structure "Private" is not known outside of the module?

Code: Select all

DeclareModule x
   DeclareStruct Public
EndDeclareModule


Module x
   Structure Private
      a.i
      b.i
      c.i
   EndStructure
   
   Structure Public
      var.Private
   EndStructure
EndModule


UseModule x

Define test.public

test\var\a = 10

So all structures which are contained in a "Public" structure have to be accessible outside of the module anyway. This is done by writing them in the "DeclareModule" section.

Another argument for adding DeclareStruct.

Code: Select all

DeclareModule x

  Declare Test(*y.Param)
  
EndDeclareModule

Module x

  Structure Param
    var.l
  EndStructure
  
  Procedure Test(*y.Param)
  EndProcedure
  
EndModule

I don't think that this is an argument for adding DeclareStruct.
If Test(*y.Param) should be accessible outside of the module, structure "Param" must be accessible outside of the module, too. The structure has to be written in the "DeclareModule" section anyway, so no "DeclareStruct" is needed.

[User_Russian]

luis, You are right. This I had not thought of.
Need a two-pass compiler....

Then maybe you need to add the keyword "Public".

Code: Select all

DeclareModule x
 
EndDeclareModule


Module x
  Structure Private
    a.i
    b.i
    c.i
  EndStructure
 
  Public Structure Public
    var.Private
  EndStructure
EndModule

Little John, Public structure contains all private structures and should be no problem.

[Little John]

Little John, Public structure contains all private structures and should be no problem.

If

Code: Select all

   Structure Private
      a.i
      b.i
      c.i
   EndStructure

is not known outside of the Module, how should the compiler know what outside of the module e.g.

Code: Select all

test\var\a = 10

means? Sorry, I can't imagine that this could work.

[luis]

Then maybe you need to add the keyword "Public".

Don't know, it's a nice problem. The idea should be all that's public is declared in the interface.
I don't have an idea I like at the moment.

@LJ

Does not work that way. The public structure contains a field defined as another structure declared as private.
This means you don't know the existence of the private structure per se, stand alone, and you can't define and instantiate a new var of that type, but you can access the public structure. If originally that structure was composed of pieces not available to you is not important, you see the end result. Totally public. The field you are worried about is not private, the original structure on which it is based upon it is.

[Demivec]

@LJ

Does not work that way. The public structure contains a field defined as another structure declared as private.
This means you don't know the existence of the private structure per se, stand alone, and you can't define and instantiate a new var of that type, but you can access the public structure. If originally that structure was composed of pieces not available to you is not important, you see the end result. Totally public. The field you are worried about is not private, the original structure on which it is based upon it is.

@luis: If you can't know the parts of the structure then why not just assign a pointer to it? If it is truly private than it would really only be manipulated inside of the module.

It could be done this way:

Code: Select all

DeclareModule x
  Structure Public
    name.s
    *var ;Private
  EndStructure
  
  Declare initPrivate(*a.public)
  Declare.s display(*a.public)
  Declare freePrvate(*a.public)
EndDeclareModule


Module x
  Structure Private
    age.i    ;years
    weight.i ;pounds
    health.i ;%
  EndStructure
  
  Procedure initPrivate(*a.Public)
    Protected *b.private
    If *a\name
      If *b = 0
        *b = AllocateMemory(SizeOf(private))
      EndIf
      *a\var = *b
      
      If *b
        *b\age = Random(60, 10)
        *b\weight = *b\age * 4 + Random(90)
        *b\health = Random (100, 30)
      EndIf 
    EndIf
  EndProcedure
  
  Procedure.s display(*a.public)
    Protected *b.private = *a\var, output.s
    
    Select *b\health
      Case 1 To 10: output + "a lifeless"  
      Case 11 To 22: output + "a sickly"
      Case 23 To 39: output + "an un-healthy"
      Case 40 To 85: output + "a healthy"
      Case 85 To 100: output + "a robust"
    EndSelect
    output + ", "
    Select *b\weight
      Case 1 To 129: output + "frail"  
      Case 130 To 164: output + "slim"
      Case 165 To 189: output + "average"
      Case 190 To 240: output + "heavy-set"
      Case 250 To 500: output + "morbidly obese"
    EndSelect
    output + ", "
    Select *b\age
      Case 8 To 15: output + "young"
      Case 16 To 30: output + "adult"
      Case 31 To 48: output + "middle-aged"
      Case 49 To 70: output + "old"
      Case 71 To 1000: output + "ancient"
    EndSelect

    ProcedureReturn output
  EndProcedure
  
  Procedure freePrvate(*a.public)
    If *a\var: FreeMemory(*a\var): EndIf
  EndProcedure
EndModule
  
Define test.x::public\name = "Joe Public"

Define i
For i = 1 To 10
  x::initPrivate(test)
  Debug "You see " + test\name + ", " + x::display(test) + " person."
Next

x::freePrvate(test) 

[luis]

@luis: If you can't know the parts of the structure then why not just assign a pointer to it? If it is truly private than it would really only be manipulated inside of the module.

Sure, I'm not saying you can't do that if you want (I mean, if you really want to keep them hidden).
Just use a pointer and some method-like procedure to get/set the hidden part, similarly to what you wrote.

I was just trying to explain what LJ found strange... and in fact that data was not really private.

All depends on what you mean with private. In your case is "not accessible or only in a controlled way, not your business what the internals are".
In the other maybe it's just "you don't need to create var of this type, use just the aggregate stuff I'm giving to you but-it's-not-a-secret-and-if-you-want-you-can-clone-my-sub-structure-I-don't-mind."

[BorisTheOld]

@luis

I think what people are failing to understand is that a module has to be treated as a "black box". Perhaps the following diatribe will help them come to grips with modules.

In effect, modules are independent blocks of code that should be looked on as something that can be compiled in its own right, such as a dynamic library (.dll/.so). Everything that a module needs has to be defined/declared within the module. It has no understanding of the outside world. Likewise, mainline code knows nothing about what is inside a module.

For modules to be able to communicate, they need a mechanism for making the contents accessable from the outside world. This is done using the DeclareModule statement. It performs the same function that the Prototype statement performs for dynamic libraries.

Modules are only grouped together in a program for convenience. The mainline code and the modules can all be compiled together as a single unit, rather than as a main executable and separately compiled libraries. As a result, one has to use the same design constraints that one uses for applications that contain dynamic libraries.

If a structure is used in the mainline, it has to be defined in the mainline. And if that structure contains instances of other structures, they also have to be defined, even if the mainline never uses them. This is even true for programs that don't use modules.

Similarly for modules. All constants, macros, and structures need to be defined within the module if they are referenced in any way. So people should try to get their heads around this, and stop coming up with all kinds of crazy ideas for getting around problems that don't actually exist.

Applications usually have constants, macros, and structures that are used throughout the code. Often they are grouped together in "Include" files. So why not just structure the code as follows, with DeclareModule statements wherever needed?

Code: Select all

;
;----------
;
;  mainline code
;
XincludeFile "Constants.pbi"
XIncludeFile "Macros.pbi"
XIncludeFile "Structures.pbi"
.
. mainline code
.
End
;
;----------
;
Module M1
XincludeFile "Constants.pbi"
XIncludeFile "Macros.pbi"
XIncludeFile "Structures.pbi"
.
. module 1 code
.
EndModule
;
;----------
;
Module M2
XincludeFile "Constants.pbi"
XIncludeFile "Macros.pbi"
XIncludeFile "Structures.pbi"
.
. module 2 code
.
EndModule
;
;----------
;
Module M3
XincludeFile "Constants.pbi"
XIncludeFile "Macros.pbi"
XIncludeFile "Structures.pbi"
.
. module 3 code
.
EndModule

[Demivec]

Applications usually have constants, macros, and structures that are used throughout the code. Often they are grouped together in "Include" files. So why not just structure the code as follows, with DeclareModule statements wherever needed?

@luis: Regarding what BorisTheOld said, wouldn't this be a suitable solution to how your library constants that modify a module's contents? It would mean that the constants would have to be placed in an include instead of a separate module declaration. On second thought, it is only slightly better.

All depends on what you mean with private. In your case is "not accessible or only in a controlled way, not your business what the internals are".
In the other maybe it's just "you don't need to create var of this type, use just the aggregate stuff I'm giving to you but-it's-not-a-secret-and-if-you-want-you-can-clone-my-sub-structure-I-don't-mind."

BorisTheOld's suggestion for includes targets this directly. luis, I appreciate your explanation because I honestly thought that private meant private or unknown/unnecessary to access. If that isn't the case then put everything in an include that can be a part of the main code or another module or just make it public. Still seems a little convoluted.


@User_Russian: Did you have a short bit of code that actually does something that illustrates what is challenging you? It seems like what you presented is more of just a riddle instead of an obstacle. I do understand if it is just a wish or a preference of some sort (I mean that's what this forum is for ).

[User_Russian]

Demivec, there is a main structure containing many nested structures (more than ten), and nested structures should not be accessible outside of the module.
At this point, we have to make public all the structures. Even if they would never used outside of the module. This violates the concept of a module as a black box.

[luis]

@luis: Regarding what BorisTheOld said, wouldn't this be a suitable solution to how your library constants that modify a module's contents? It would mean that the constants would have to be placed in an include instead of a separate module declaration. On second thought, it is only slightly better.

Sorry, I don't follow you. Are you talking about the problem I had in this thread -> http://www.purebasic.fr/english/viewtop ... 99#p416699 ? In any case I don't understand what you mean. Keep in mind in that case the constants used to pilot the conditional compilation must be set by a third party, the user of the lib.